Who Are You, and What May You Do? Authentication and Authorization Explained Clearly

The support employee enters the office without trouble. The guard checks the photo identity card, confirms the face, and lets the employee through. Minutes later, the same employee opens the finance screen and issues a large refund. The login was genuine. The person was exactly who the system believed they were. The failure happened after identity was known.

This is the cleanest way to separate two words that are often pushed into one sentence. Authentication answers whose request this is. Authorization decides whether that identity may perform this exact action on this exact resource. The employee passed authentication at the entrance but should have failed authorization at the refund action.

The visible symptom is an unauthorized refund by a correctly authenticated user. The technical cause may be a missing server-side check, an overbroad role, or a policy that treats 'employee' as permission for every internal action. The design decision is least-privileged, resource-and-action-specific authorization. The consequence is safer separation of duties, at the cost of policy design, testing, review, and operational support.

Authentication gives a request an identity; authorization gives that identity a boundary.

Read the visual as three separate decisions. The entrance verifies the person. The floor badge applies a broad workplace policy. The refund service makes the final action-and-resource decision. The repeated checks are not wasteful duplication; each protects a different boundary.

Identity, Credential, Factor, and Claim Are Different Things

An identity is the person, service, device, or workload being represented. A credential is evidence presented during a process: a password, private-key proof, session identifier, or identity-provider response. A factor describes the kind of evidence. A claim is a statement such as subject ID, email, department, role, issuer, or authentication time.

Traditional factors are something you know, something you possess, and something you are. A password and a PIN are two secrets, but they are both knowledge factors. Two passwords do not become multi-factor authentication simply because the user typed twice. A phone approval plus a password combines possession and knowledge, assuming the second factor and recovery path are genuinely independent.

Claims are inputs, not unquestionable truth. A service must know who issued a claim, who it was intended for, when it expires, and whether it is relevant to the current decision. A claim saying `role=support` does not automatically prove the user may refund order 9182. The resource service still evaluates policy.

Analogy limit: a plastic badge does not model cryptographic proof, replay, browser theft, key rotation, session expiry, account recovery, or distributed revocation. Use it to remember the decision, not to design the protocol.

Passwords Are Verified, Not Decrypted

At registration, a secure system does not store the user's original password and should not store an encrypted copy that administrators can recover. It generates a unique salt and runs the password through a purpose-built, deliberately expensive password-hashing function. The stored record contains the resulting verifier plus the salt and parameters needed to test a future attempt.

At login, the server takes the submitted password, uses the stored salt and work parameters, recomputes the verifier, and compares the result. If the password database leaks, an attacker must still guess candidate passwords and pay the hashing cost for each guess. A unique salt prevents one precomputed answer from working across many users with the same password. The salt is normally stored beside the verifier; it is not a secret.

Do not use a fast general-purpose hash such as SHA-256 for password storage. Current OWASP password-storage guidance recommends purpose-built choices such as Argon2id, with scrypt as a fallback, bcrypt for legacy environments, or PBKDF2 where specific requirements apply. The exact parameters must reflect the environment and be reviewed over time.

Password hashing protects an offline database leak; it does not stop online guessing through the login endpoint. Rate limits, breached-password screening, monitoring, sensible password policy, MFA, secure recovery, and session protection address other paths. One control cannot carry the whole identity system.

MFA: One Stolen Secret Should Not Be Enough

Imagine the attacker has the employee's password. A second independent factor can interrupt the login, but factor quality matters. Manually entered OTP codes and SMS messages can be phished or redirected. Push prompts can be approved by mistake. Hardware security keys and passkeys can provide stronger phishing resistance because the proof is bound to the legitimate site, though device availability and recovery still need design.

What this table is telling you is that MFA is a system, not a checkbox. Enrollment, factor replacement, lost devices, help-desk verification, backup codes, and emergency access can become easier bypasses than the factor itself. The latest NIST Digital Identity Guidelines are useful because they distinguish authenticator assurance and phishing resistance instead of treating every second step as equal.

Pause and retrieve

Without rereading, explain identity, credential, factor, and claim using four different sentences. Then explain why a salted password hash and a login rate limit protect against different attack paths.

Server-Side Sessions: Reception Remembers the Keycard

A hotel verifies a guest at reception, records the stay, and issues a keycard linked to that record. In a server-side web session, the application verifies login evidence, creates a session record containing a user reference and security state, and sends the browser an opaque session identifier, usually in a cookie. The identifier is a lookup key, not the entire user profile.

1. The user submits authentication evidence over a protected connection.

2. The server verifies it and creates a fresh session record.

3. The browser receives an unpredictable identifier in a Secure, HttpOnly, appropriately scoped cookie.

4. Each later request presents the cookie; the server loads the session and then authorizes the requested action.

5. Privilege changes, suspicious activity, logout, inactivity, or absolute lifetime can rotate or invalidate the session.

Session fixation occurs when an attacker causes a victim to use an identifier the attacker already knows; rotating the identifier after authentication or privilege change helps. Session hijacking occurs when an active identifier is stolen. Secure cookie attributes reduce exposure, but XSS can still make harmful same-origin requests, and CSRF remains a concern when browsers attach cookies automatically.

CSRF and XSS are not arguments for or against cookies in one sentence. Secure, HttpOnly cookies keep JavaScript from directly reading the identifier, but a malicious script running on the legitimate origin can still act as the user. SameSite policy and anti-CSRF tokens help distinguish cross-site requests, while output encoding, safe DOM APIs, content-security policy, and dependency discipline reduce script injection. The browser threat model must be designed as a whole.

Session state can also carry security facts that change quickly: recent MFA time, device approval, tenant selection, password-change time, impersonation mode, or forced logout. Keeping those facts server-side can simplify immediate invalidation. The cost is an available and consistent session service, bounded session size, cleanup, and careful behavior when the store is slow or unreachable.

Sessions are not inherently unscalable. A distributed application can use a shared session store, route consistently, or keep carefully bounded server-side state. The tradeoff is lookup availability, replication, cleanup, and cache/store operations. For a fuller browser and cookie foundation, see Web Concepts in System Design.

Read the diagram in a loop: login creates server state, the browser carries only the opaque key, each request performs a lookup and policy decision, and logout invalidates the record. Remember which side holds the meaningful session state.

Tokens and JWT: The Signed Pass Is Not a Permission Slip for Everything

A signed event pass can carry the attendee name, issuer, event, permitted area, and expiry. A token can similarly carry or reference claims. A resource server validates the token's issuer, intended audience, lifetime, signature or introspection result, and relevant constraints before trusting those claims. It must then make its own authorization decision for the requested resource.

JWT is a compact token format with a header, payload, and signature or authentication result depending on its form. A common signed JWT protects integrity and authenticity of the claims under its key model. The payload is encoded, not automatically encrypted. Anyone holding such a token may be able to read its claims, so sensitive secrets and unnecessary personal data do not belong there.

An access token is presented to a resource server. An ID token communicates an authentication event and identity claims to the client in OpenID Connect. A refresh token is a high-value credential used with the authorization server to obtain fresh access tokens. Using an ID token as an API access token or exposing refresh tokens broadly confuses trust boundaries.

Self-contained validation can reduce a central lookup on every request, but it shifts complexity into short lifetimes, key distribution, audience design, rotation, theft response, and revocation. A stolen bearer token can be replayed until it expires or is otherwise rejected. Sender-constrained designs can reduce replay in appropriate systems, but add operational requirements.

Read the visual in two stages. First, validate the token as evidence: issuer, audience, expiry, and signature. Second, evaluate the requested action and object. A green first stage does not force a green second stage.

Token Theft, Replay, Expiry, and Revocation

A bearer token works for whoever presents it. If malware, an unsafe browser store, a log, a referrer, a mobile backup, or a compromised proxy leaks the token, an attacker may replay it from another device. TLS protects transit between endpoints but does not erase copies created at an endpoint. Keep access tokens short-lived, audience-bound, minimally scoped, and out of URLs and ordinary logs.

Expiry limits the replay window but does not respond immediately. A deny list or revocation store can stop selected tokens at the cost of state and lookup availability. Introspection keeps the authorization server involved in token status. Rotating signing keys invalidates a broad class of tokens and can cause a large outage if done carelessly. The correct choice depends on how quickly access must stop after theft.

Refresh tokens deserve stronger storage and rotation because they mint new access. A public client may use refresh-token rotation so each successful use returns a replacement and reuse of an older token signals theft. The server then revokes the token family or related session. Device/session lists and consent revocation help users and administrators act without waiting for access-token expiry.

Sender-constrained tokens can bind use to proof of a private key or a protected transport client, reducing value to a thief who only copies the token. This is not free: clients need key handling, servers need verification and replay state, and proxies must preserve the right context. Use the additional machinery where the risk justifies it.

Design an incident action, not merely a token format: identify the affected session or device, revoke refresh capability, block or wait out short access tokens, rotate credentials only at the required scope, notify the user, preserve evidence, and review how the credential escaped.

Session or Token Is an Architecture Decision, Not a Fashion Vote

What this table is telling you is that neither design wins by slogan. A first-party server-rendered application often benefits from an opaque secure cookie and central invalidation. A mobile client calling several APIs may benefit from short-lived audience-scoped access tokens and a carefully protected refresh flow. Hybrid systems are common: the browser has a server session while the backend obtains tokens for downstream APIs.

Choose the credential shape from the revocation, client, trust-boundary, and operational requirements - not because JWT sounds modern.green

OAuth 2.0 Delegates Access; OpenID Connect Adds Login Identity

A photo-printing service asks for permission to read selected photos without learning the user's cloud-storage password. That is delegated authorization. OAuth 2.0 defines how a client obtains limited access to a resource on the user's behalf. The authorization server, client, resource owner, resource server, scopes, consent, and access token all belong to that delegation.

Now consider 'Sign in with an identity provider'. The client needs a standard statement about the authentication event and user identity. OpenID Connect adds that identity layer on top of OAuth 2.0, including an ID token and user-information semantics. OAuth alone should not be described as a login protocol.

For a modern public client, Authorization Code with PKCE is the baseline flow. The client creates a secret verifier and sends its derived challenge with the authorization request. After the user authenticates and grants consent, the client receives a short-lived authorization code. It redeems that code with the original verifier, making a stolen code less useful to another process.

The client also validates redirect handling and correlates the response with its request. In OIDC, nonce and ID-token validation protect the authentication exchange. The resource server validates access-token audience and scopes or permissions. Current OAuth Security Best Current Practice deprecates weaker historical patterns and strengthens guidance around PKCE, redirect URIs, token replay, and sender constraints. The identity layer itself is defined by OpenID Connect Core.

Read the flow by following artifacts, not arrows alone: browser authorization request, code plus PKCE verifier, access token for the API, and ID token for the client. The tokens have different audiences because they answer different questions.

RBAC, ABAC, DAC, and MAC Decide Permission Differently

Role-based access control, or RBAC, gives permissions to roles and assigns people or workloads to those roles. `Support agent` may view an order and add a note; `finance approver` may issue a refund. RBAC is understandable and auditable, but too many special cases can create role explosion.

Attribute-based access control, or ABAC, evaluates subject, resource, action, and environment attributes. A refund may be allowed when the employee is in Finance, the order belongs to the employee's region, the amount is below a threshold, the device meets policy, and the request occurs during an approved shift. ABAC expresses rich rules but can become difficult to test and explain if attributes and policy ownership are weak.

What this table is telling you is that these models can coexist. A role may provide a baseline, attributes may narrow it, and object ownership may matter inside the action. The refund service should not trust a role claim alone if order ownership, amount, approval chain, or separation of duties changes the decision.

Read both lanes using the same refund. RBAC asks which permissions the role carries. ABAC also asks who, what object, which action, under which context. Remember that richer policy buys flexibility by increasing testing and governance work.

Least Privilege, Default Deny, and Separation of Duties

Least privilege grants only the access needed for the current job. Default deny means an action remains forbidden until an explicit rule allows it. Separation of duties prevents one identity from initiating, approving, and hiding a sensitive operation alone. Together, these choices reduce blast radius when an account or service is compromised.

Enforcement belongs on the server or trusted service boundary. Hiding the Refund button improves user experience; it does not prevent a crafted API request. Check the action against the resource on every relevant request, avoid predictable-object assumptions, review permissions, use time-limited elevation for exceptional work, and log both privileged success and meaningful denial.

Identity lifecycle is authorization work too. Joining, changing teams, becoming a contractor, going on leave, and leaving the company should change roles and sessions predictably. Remove access from the source of truth, revoke privileged sessions, rotate shared credentials that should never have been shared, and review orphaned service accounts. A perfectly written policy cannot help if old identities remain active indefinitely.

Emergency access needs a separate path: strong proof, short duration, narrow scope, explicit reason, high-signal monitoring, and post-use review. If every administrator uses the emergency role daily, it is no longer a break-glass control; it is the normal overprivileged role wearing a dramatic name.

SSO and Federation: One Login, Larger Consequences

Single sign-on lets a user authenticate through one identity system and access several applications without entering separate credentials for each. Federation lets organizations or security domains trust identity assertions under agreed protocols and policy. OIDC and SAML can support SSO, but SSO describes the experience and architecture, not one protocol.

Central identity can improve MFA enforcement, provisioning, removal, monitoring, and user experience. It also concentrates impact. An identity-provider outage can block many applications; a compromised central administrator or signing key can affect broad trust. Applications still own local authorization, session lifetime, logout behavior, and emergency access decisions.

Pause and retrieve

Explain the refund failure using authentication, authorization, role, resource, action, and least privilege. Then explain why central SSO can simultaneously reduce password risk and increase the blast radius of one identity-system failure.

A Distributed Identity Flow Without Hand-Waving

A browser or mobile client begins an Authorization Code with PKCE flow at the identity provider. After authentication and consent, the client obtains the artifacts appropriate to its role. It calls an API gateway or resource server with a short-lived access token. The resource server validates issuer, audience, expiry, signature or introspection result, and then evaluates authorization for the requested order.

If the order service calls the payment service, it should not blindly forward every user token. The architecture decides whether the payment service needs delegated user context, a workload identity, a token exchange, or a tightly scoped service credential. Audience must match the receiving service, and the payment service still enforces its own action policy. The request path concepts in Protocols in System Design make those boundaries easier to draw.

Operationally, the team needs signing-key rotation, clock-skew handling, short access-token lifetimes, refresh-token protection and reuse detection where relevant, session/device review, rate limits on authentication endpoints, privacy-aware audit logs, and a revocation story. The correct design is the one the team can operate during theft, outage, employee removal, and key rotation - not only during a successful demo.

Interview phrasing: I separate identity proof from permission. I choose sessions or tokens from client and revocation needs, validate issuer/audience/expiry, authorize the exact action on the resource at the owning service, and design recovery, rotation, and audit as part of the flow.

Common Misunderstandings That Create Real Incidents

• Logged in means allowed. Authentication establishes identity; every sensitive action still needs authorization.

• JWT is encrypted. A common signed JWT protects integrity but leaves encoded claims readable.

• JWT means no server state. Revocation, consent, keys, sessions, devices, and risk state may still exist.

• OAuth is login. OAuth delegates access; OpenID Connect adds identity semantics for authentication.

• Roles are always enough. Object, action, ownership, amount, location, and time may change the decision.

• Hiding a button is authorization. A caller can bypass the interface and send the request directly.

• Long-lived tokens are harmless convenience. A longer lifetime extends the replay window after theft.

• Strong MFA makes recovery safe automatically. A weak help-desk or recovery flow can bypass the strong factor.

Explain It Back Without Looking

Cover the article and reconstruct the opening incident: known employee, forbidden refund. State the symptom, technical cause, policy decision, consequence, and operational tradeoff. Then match photo ID, floor badge, hotel ledger, signed pass, and valet key to their technical jobs.

1. Draw registration and password verification without drawing a decrypt step.

2. Draw a server-side session: login -> session record -> opaque cookie -> lookup -> authorization -> invalidation.

3. Draw Authorization Code with PKCE and place the access token and ID token at their correct audiences.

4. Contrast authentication/authorization, session/token, access/ID/refresh token, OAuth/OIDC, and RBAC/ABAC.

5. Apply the design to a support tool where agents may view assigned orders but refunds above a threshold require a separate finance approver.

A sixty-second retelling might sound like this: authentication verifies the identity behind a request, while authorization decides whether that identity may perform an action on a resource. Passwords are verified with salted, slow password hashes; MFA adds independent proof; sessions and tokens carry identity state with different revocation and client tradeoffs. OAuth delegates access, OIDC adds login identity, and RBAC or ABAC expresses policy. Every sensitive service enforces least privilege and records important decisions.