Overview
Curated: · Written: · Reviewed:
Key takeaways
- Authentication establishes confidence that a claimant controls authenticators bound to an account; authorization decides whether that subject may perform a specific action on a specific resource under current context. Authorization always consumes a prior authentication or a trusted assertion about identity — a system that authorizes before it authenticates is broken.
- Identity proofing, authentication, federation, session management, and authorization are distinct controls. A strongly authenticated subject can still be unauthorized, and a valid session or token is not blanket permission.
- Enforce authorization server-side on every request, deny by default, validate tenant and object ownership, and derive the trusted subject from verified session or token state — never from client-supplied user IDs.
- OAuth is an authorization delegation framework, not an authentication protocol. "Logging in with OAuth" is really OpenID Connect layered on top. Access tokens target resource servers; ID tokens communicate authentication claims to the client and should not be sent as generic API authorization.
- Sessions and access tokens are capabilities. Protect them in transport and storage, restrict audience, scope, and lifetime, rotate on privilege changes, and plan revocation — including the hard problem of a cryptographically valid token after logout or password reset.
- Recovery, enrollment, authenticator change, step-up, delegated access, impersonation, service accounts, and administrative operations need explicit threat models, audit trails, tests, and defined failure behavior.
1. The distinction, and the ordering that goes with it
Interviewers open with "what's the difference between authentication and authorization?" and most candidates answer it fine. The follow-up is where the answer is won: which comes first, and what does authorization consume? Authorization is downstream. It takes a subject established by authentication (or vouched for by a federated assertion under a trust agreement) and answers a separate question: may this subject do this action on this resource, right now, in this context. A system that authorizes before it authenticates has nothing trustworthy to authorize against.
A weak answer stops at "authentication is who you are, authorization is what you can do" and treats the two as parallel concerns. A strong answer names the seam between them — the session or token — and points out that authorization bugs are easy to underinvest in, because teams pour effort into login flows and then treat a logged-in user as a trusted user.
Do not treat a username, email, client-submitted account ID, UI route, network location, or decoded-but-unverified token as an authenticated identity. Authentication strength should match risk and step up for sensitive changes, but reauthentication is not authorization: after proving who someone is, the service still checks what they may do now.
2. The classic boundary case: OAuth, OIDC, and what each token proves
This is the most common trap question in the area. OAuth 2.0 (RFC 6749) is a delegation framework: a resource owner grants a client limited access to a resource server. It says nothing about who logged in. When a product offers "sign in with Google," the login part is OpenID Connect — an identity layer on OAuth 2.0 that adds an ID token and a UserInfo endpoint.
The two tokens prove different things:
- Access token: presented to a resource server, scoped and audience-bound. It proves the client was granted access to something — not that the end user is present, and not that the user owns every object the client references.
- ID token: a signed JWT (in the common case) whose audience is the client, carrying authentication claims — issuer, subject, when authentication happened, nonce. It is for the client to validate an authentication event. Sending it as a Bearer credential to an API is a recurring real-world bug: the API either rejects it or, worse, validates the signature without checking audience and accepts it.
A weak answer conflates the two or says "OAuth is how users log in." A strong answer can say: OAuth delegates, OIDC authenticates, and the audience claim is what keeps the two from being interchangeable.
3. Tokens and sessions: the mechanics at the seam
JWT validation obligations
A JWT is three base64url segments — header, payload, signature. Validating it is not decoding it. The obligations:
- Verify the signature with the right key, and pin the allowed algorithms (never let the header choose
alg; thenonealgorithm and algorithm-confusion attacks are the canonical failures). - Check
iss(issuer),aud(audience — this API must be in it),expandnbf, with a small clock-skew tolerance. - Check scope or other required claims for the specific endpoint.
- Resolve keys through a JWKS endpoint with caching and key rotation handling.
Stateful session vs stateless token
| Server-side session | Stateless JWT | |
|---|---|---|
| Storage | Server state; client holds an opaque ID | All claims in the token; no server lookup |
| Revocation | Delete/invalidate server-side — immediate | Hard: token is valid until exp unless you add a denylist or introspection |
| Per-request cost | A store read | Signature verification only |
| Claim freshness | Always current | Frozen at issuance |
The "valid token after logout" problem is the standard follow-up: short lifetimes (minutes) plus refresh tokens bound to server-side state is the usual compromise, because revoking a refresh token cuts the chain at the next renewal. Reference tokens — opaque tokens introspected at the authorization server — trade the stateless advantage back for immediate revocation.
Session hygiene
Generate session identifiers with sufficient entropy, store server-side state or carefully validate protected claims, and use Secure, HttpOnly, SameSite cookies appropriate to the flow. Rotate identifiers after authentication and privilege changes to prevent fixation. Define idle and absolute timeouts, logout and server-side invalidation, device/session visibility, and reauthentication for sensitive operations. Cookie-authenticated state-changing requests need CSRF defenses; XSS can still act as the user even when HttpOnly prevents direct token reading.
Bearer tokens grant access to whoever possesses them: use TLS, keep them out of URLs and logs, and remember that a short lifetime limits exposure but does not prevent replay during validity — sender-constrained tokens (DPoP, mTLS-bound) reduce that. Refresh tokens need stronger storage, rotation with reuse detection, client binding, and revocation.
For public clients, use the authorization code flow with PKCE, exact redirect URI matching, state for transaction binding, issuer validation, and an OIDC nonce — each closes a different attack surface.
4. Where the two fail differently
This is the section interviewers actually fish for, because it shows whether you've debugged real systems.
Authentication failures are about impersonating or exhausting the subject: credential stuffing, phishing, MFA fatigue (push-bombing until the user approves), missing rate limiting and lockout, enumeration-friendly error messages, session fixation, weak recovery flows.
Authorization failures are about an authenticated subject reaching things they shouldn't: IDOR (changing /invoices/813 to 812), horizontal vs vertical privilege escalation, missing function-level checks (an admin endpoint that only the UI hides), confused deputy (a service with broad permissions acting on a caller's unvalidated instruction), cross-tenant leakage, stale policy caches after revocation.
The point to land: a strong login proves nothing about correct authorization. IDOR findings routinely sit behind a login flow that works exactly as designed — the password check and MFA prompt succeed, and the object-level check is simply missing. If asked "we have MFA, are we safe?" the answer is that MFA raises authentication assurance and leaves object-level authorization exactly as broken as it was.
5. Authorization models and the judgement behind choosing one
- RBAC assigns permissions through roles. Simple, auditable, and it rots into role explosion — hundreds of near-duplicate roles nobody dares delete.
- ABAC evaluates attributes and context (department, device posture, time, data classification). Expressive, but policy is harder to test and explain.
- ReBAC follows relationships ("the owner of the parent document"). Fits collaborative and graph-shaped data; the policy engine becomes part of your critical path.
Real systems combine them: roles coarse-grained, attributes and relationships fine-grained. Whatever the model, three rules hold. Least privilege and separation of duties shape the roles themselves. Default-deny beats default-allow — access requires an explicitly applicable rule, and the resource-owning service fails closed when policy data is unavailable or ambiguous. And enforcement lives at the resource, never at the client: hiding a button is not an access control.
Cache authorization only with subject, tenant, policy version, resource, action, context, TTL, and invalidation semantics that prevent stale privilege.
6. Lifecycle, delegation, services, and privileged operations
Enrollment and recovery are often weaker than login and become account-takeover paths. Apply equivalent risk controls to authenticator addition, password reset, email/phone change, recovery-code use, and account linking: notify through existing trusted channels, invalidate appropriate sessions and tokens, rate-limit, avoid knowledge questions, and keep support and appeals from becoming an authorization bypass.
Delegated access — one user acting on another's behalf, an assistant reading a mailbox, a support agent working a ticket — needs its own model: explicit grant and scope, revocation by either party, audit records that distinguish the actor from the effective subject, and expiry. Delegation is authorization with two subjects, and systems that model it as "share my password" or a blanket role fail both.
Service accounts and workload identities need non-human ownership, purpose, audience, least privilege, short-lived credentials where possible, rotation, usage telemetry, and decommissioning. Administrative impersonation should be exceptional, time-bounded, approved, visibly indicated, audited as both actor and effective subject, constrained from high-risk actions, and revocable. Break-glass access needs strong authentication, explicit scope, alerting, review, and post-use rotation — not a shared permanent superuser password.
7. Testing and operations
Build an authorization matrix of subject/role/tenant/relationship × resource × action × state, and test allowed and denied cases: ID substitution, nested and bulk endpoints, stale policy caches, revocation, race conditions, missing context, cross-tenant boundaries. Authentication tests cover enumeration-safe errors, rate limiting, session fixation, CSRF, replay, redirect validation, token claims, recovery, MFA changes, logout, and concurrent sessions.
Log authentication and authorization outcomes without credentials or bearer tokens: actor, effective subject, tenant, resource type/identifier as privacy permits, action, policy version, reason code, assurance level, request/correlation ID, and administrative context. Monitor failures and anomalous access, but do not treat heuristics as proof. Policy changes are versioned releases with review, simulation, canary, rollback, and audit reconciliation.
Worked example: one invoice, four requests
Invoice 812 belongs to user A in tenant acme. Invoice 813 belongs to user B. The resource server must answer two questions in order: who is the subject, then may that subject read this object.
| request | authentication | object authorization | status |
|---|---|---|---|
| GET /invoices/812 with A's session | subject A | owner is A | 200 |
| GET /invoices/813 with A's session | subject A | owner is B | 403 |
| GET /invoices/812 with no session | no subject | not evaluated | 401 |
| GET /invoices/812 with an ID token as Bearer | not an access token for this API | not evaluated | 401 |
Authenticated and authorized are not the same row. A 401 means the server does not have a trusted subject. A 403 means it does, and that subject is not allowed this object. Sending an ID token as a generic API credential fails the first question — its audience is the client, not this API — so it never reaches the owner check.
If an interviewer pushes on the last row, the follow-up worth having ready: the failure is only a 401 if the API actually validates aud. An API that verifies the signature but skips audience checking will treat that ID token as valid and authorize user B's claims against invoice 812 — a 200 that should have been a 401.