Security and Authentication in System Design

A customer signs in and requests an order. The service needs to establish who the customer is and whether that customer may access this particular order. Those are different decisions.

Authentication establishes identity under a defined mechanism. Authorization decides permitted actions and resources. Security also includes protecting data, secrets and interfaces against misuse throughout the request path; a login screen alone does not establish that protection.

Use reviewed framework or identity-provider implementations instead of inventing password cryptography or token validation. If handling passwords, follow current storage guidance and suitable password-hashing implementations; do not store plaintext or use a general fast hash alone.

Protect credential transport, session creation, expiry and revocation under the application’s threat model. Browser sessions need appropriate cookie and request protections; bearer tokens need careful storage and validation of the intended trust boundary.

Multi-factor authentication can improve resistance to some account attacks, but does not replace permission checks or safe recovery flows. Rate limits, account recovery and error messages need deliberate abuse and privacy behaviour.

A valid user identifier is not permission to read any order ID supplied by that user. Query or evaluate ownership, role and policy at the relevant server-side boundary. Default to denying access unless an explicit rule permits it.

Hiding a button in the browser can help the interface, but an attacker can send a request directly. The authoritative check must protect the operation regardless of which client calls it.

Services calling each other also need appropriate identity, permissions and input validation. A request arriving from an internal network is not proof that every requested operation is allowed.

Explore two read-only permission scenarios. The cards describe the consequences of each design. This is a teaching review; it does not implement a production authentication system.

Any real implementation needs a threat model, suitable framework controls and tests for allowed and denied requests.

Give application components the permissions they need for their responsibilities, rather than broad credentials for convenience. Keep secrets in appropriate protected configuration or secret-management systems, and plan rotation and revocation.

Validate inputs and use safe database and output APIs. Protect file uploads and outbound fetching according to their boundaries. A signed URL, proxy or cache must not bypass the resource’s actual access policy.

Collect useful audit outcomes while avoiding passwords, tokens and unnecessary personal data in logs. Test expiry, removed roles, logout and account changes rather than only successful sign-in.

The OWASP Authentication Cheat Sheet and Authorization Cheat Sheet provide implementation review guidance. Sources checked 6 October 2026. Use the selected framework’s current controls and library documentation as well.

For a small web application, a mature session-based framework may meet the need. An external identity provider can help shared identity or organisational requirements, while introducing integration, availability and commercial choices.

Choose identity mechanisms from the users, clients and threat model. “Use JWT” is not a complete decision about permissions, token theft, expiry or revocation.

A Proxy can mediate access and a request-check chain can organize enforcement. These structures must still check the protected resource on the server; a client wrapper cannot grant or revoke authority by itself.

Use mature authentication mechanisms and explicit server-side permission rules. Protect credentials, sessions, data and service boundaries together.

Follow current primary guidance, test denied and expired access, and keep sensitive values out of telemetry. Security requirements need implementation evidence, not architecture labels alone.