Questions › Networking/Security
Distinguish authentication from authorization, then compare session-cookie auth with token (JWT) auth. What are the trade-offs?
Getting the two 'auth' concepts straight, and understanding the real trade-offs between stateful sessions and stateless tokens.
AUTHENTICATION (authN) is proving WHO you are — logging in with a password, passkey, or OAuth. AUTHORIZATION (authZ) is deciding WHAT you're allowed to do once identified — roles, permissions, ownership checks. They're sequential and distinct: you authenticate once, then every protected action requires an authorization check. The classic status codes map to them: 401 = not authenticated, 403 = authenticated but not authorized. A common security bug is doing authN but skimping on authZ — e.g. trusting a resource id from the client without checking the logged-in user actually owns it (IDOR / broken object-level authorization). Now, two ways to carry the authenticated identity across requests. SESSION-COOKIE (stateful): on login the server creates a session, stores its state server-side (in memory, Redis, a DB), and sends the client an opaque session id in a cookie. Each request carries the cookie; the server looks up the session. Pros: the server can INVALIDATE a session instantly (logout, ban, password change just delete it); the cookie is opaque so no sensitive data leaves the server; with HttpOnly+Secure+SameSite it's well-defended. Cons: requires server-side session storage (a scaling/sharing concern across many servers); cookies bring CSRF exposure (mitigated by SameSite). TOKEN / JWT (stateless): on login the server issues a signed JSON Web Token containing claims (user id, roles, expiry); the client stores it and sends it, typically as Authorization: Bearer <token>. The server VERIFIES THE SIGNATURE and trusts the claims without a lookup. Pros: stateless and horizontally scalable (any server can verify with the key, no shared session store), natural for APIs and cross-service auth. Cons: REVOCATION is hard — a valid signed token works until it expires, so 'log out everywhere' / instant ban needs extra machinery (short lifetimes + refresh tokens, or a server-side denylist, which reintroduces state); tokens can be bloated; and if stored in localStorage they're readable by XSS. The pragmatic pattern many apps land on: short-lived access tokens for statelessness PLUS a long-lived refresh token stored in an HttpOnly cookie, giving you scalability with a revocation point — or simply session cookies for a classic server-rendered app, since they're simpler and safely revocable. The right choice is about revocation needs and architecture, not fashion.
Designing an auth system; choosing sessions vs tokens; explaining a 401 vs 403 or an IDOR bug.
AuthN = who are you (login) 401 = not authenticated
AuthZ = what may you do (permissions) 403 = authenticated, not allowed
(always re-check ownership per request -> avoid IDOR)
Session cookie (stateful) JWT / token (stateless)
Storage server-side session store nothing server-side (signed)
Carried in Cookie (auto-sent) Authorization: Bearer (JS-attached)
Revocation instant (delete session) hard (valid until expiry)
Scaling needs shared session store any server verifies with the key
CSRF exposed (mitigate: SameSite) not via ambient cookie
XSS token theft HttpOnly cookie -> no localStorage -> yes
Common hybrid: short-lived access token + refresh token in an HttpOnly cookie.