AuthN, AuthZ, sessions & JWT

Core details

AuthN verifies identity; AuthZ evaluates per-object permissions (never only coarse roles if data is multi-tenant sensitive).

Cookie session (HttpOnly, Secure, SameSite) resists trivial JS exfiltration yet requires CSRF defenses for ambient credentialed writes.

JWT / opaque bearer tokens simplify cross-service hops but stored in JS memory/localStorage worsen XSS blast—pair with short TTL + rotation + hardened XSS surface.

Validate JWT claims: iss, aud, exp (and nbf when used), verify signatures with rotation via kid—never “decode-only” pretending that is security.

Problem this solves: a user proving identity is not the same as being allowed to read or mutate a specific object.

Simple mental model: AuthN answers “who are you?” AuthZ answers “may this identity perform this action on this resource right now?”

Authorization belongs next to authoritative data, not sprinkled only at the edge—duplicated FE checks diverge silently. JWT “statelessness” trades away instant revocation unless you add short TTL + refresh choreography or explicit revocation infrastructure—say that plainly in interviews.

Session/token trade matrix

Choice	Strength	Risk	Good fit
Server session cookie	revocation and server control	CSRF if ambient writes are not protected	browser apps with central backend
Short-lived JWT	cheap service-to-service verification	revocation delay, token theft blast radius	APIs with clear issuer/audience boundaries
Opaque bearer token	introspection and revocation	network call or cache required	high-control enterprise/security contexts
Refresh token rotation	limits long-term theft	complex replay detection	long-lived user sessions

Store tokens based on threat model. Browser localStorage increases XSS blast radius; cookies need CSRF defenses and SameSite policy.

Senior understanding

Prompt	Response shape
IDOR	demonstrate object-level test matrix mentally
Broken logout	server-side session invalidation semantics
Tenant isolation	predicates + integration tests blocking cross reads

Link to /security for browser attack coupling when FE stores tokens.

Common mistakes

Checking only “role = admin” and forgetting object ownership.
Decoding JWT payload without verifying signature and claims.
Using one global cache key for permissioned data.
Assuming logout invalidates every JWT without revocation or short TTL.
Trusting frontend-hidden buttons as authorization.

Interview answer structure

“I separate authentication from authorization. The edge can authenticate and reject obviously invalid tokens, but object-level authorization happens near the data. I verify issuer, audience, expiry, signature, and key rotation. For browser sessions, I weigh HttpOnly cookies plus CSRF protection against bearer-token XSS risk. For multi-tenant data, tenant predicates and integration tests protect every read path.”

Follow-ups to expect:

How do you prevent IDOR?
What breaks when a signing key rotates?
How does logout work for JWTs?
Where should authorization logic live in a microservice system?

Diagram

Loading diagram…