Sessions vs tokens

Two ways to remember a logged-in user

After a user proves who they are, the server has to remember that fact across every later request, because HTTP itself is stateless — each request arrives with no memory of the last. There are two dominant ways to carry that “you are logged in” fact, and they sit at opposite ends of one axis: where the truth lives.

A server session keeps the truth on the server. At login the server creates a record — session_id → {user_id, created_at, roles, …} — in a store (Postgres, Redis, a signed encrypted cookie store) and hands the client an opaque random session_id in a cookie. The cookie is just a lookup key; it means nothing on its own. Every request, the server takes that id, looks up the record, and that record is the source of truth. This is stateful: the server holds session state and consults it on every call.

A bearer token (a JWT is the common shape) keeps the truth in the token. At login the server builds a small JSON payload — {sub: user_id, roles, exp} — and signs it with a secret. The client stores the token and sends it on every request, usually as Authorization: Bearer <token>. The server verifies the signature with the same secret and believes the claims inside — no database lookup, no shared store. This is stateless: any server holding the verification key can validate the token alone. “Bearer” is literal: possession is authorization. Whoever holds the token is treated as the user, exactly like cash.

The real tradeoff: revocation latency vs lookup cost

People sell tokens as “scalable, no database hit per request” and sessions as “old and slow.” That framing hides the actual decision. The honest tradeoff is a swap of one cost for another.

Sessions buy you instant revocation by paying a per-request lookup. Because the server reads the session record on every call, you can change or kill it at any moment: delete the row to force logout, flip a roles field to demote a user mid-session, or invalidate every session for an account after a password reset. The cost is that lookup — a Redis GET is sub-millisecond, a Postgres read more — and the store is now a dependency on the hot path of every authenticated request.

Tokens buy you a stateless hot path by paying with revocation you don’t have. There is no per-request store call, so any node with the key validates independently — that genuinely helps a fleet of stateless services and cross-domain APIs. But the same property that removes the lookup removes the place to say “stop.” A signed token is valid until its exp passes; the server has no record to delete. So the moment you need real revocation — logout-everywhere, a stolen token, an emergency demotion — you have to bolt state back on (a denylist, a short-lived-access-plus-refresh scheme), at which point you are paying a lookup again and the “stateless” advantage you bought it for is partly gone.

That is the senior framing: you are not choosing fast vs slow, you are choosing where revocation latency lives. Sessions put it at zero and charge a lookup. Pure tokens push it out to the token’s lifetime and charge you an incident when that window is wrong.

Where each one breaks

Each design has a signature failure mode, and knowing them is how you pick.

Sessions break on session fixation and on the store. Session fixation: if the server accepts a session id supplied by the attacker (e.g. from a crafted link) and then upgrades that same id to authenticated on login, the attacker — who already knows the id — is now logged in as the victim. The fix is non-negotiable and one line of discipline: regenerate the session id on every privilege change, especially at login, so the pre-auth id can never carry into an authenticated session. Sessions also make the store a hard dependency: if Redis is down, nobody is authenticated, so it needs the same availability as the app itself.

Tokens break on revocation and on storage. Revocation: covered above — a leaked token is good until exp, and “logout” is a lie unless you’ve added a denylist or short expiry. Storage: a bearer token is cash, so where the browser keeps it decides the blast radius. In localStorage it is readable by any JavaScript on the page, so a single XSS exfiltrates it; in an HttpOnly cookie it is invisible to JS (XSS can’t read it) but now rides along automatically and you’ve re-introduced CSRF exposure that you must counter with SameSite and anti-CSRF tokens. There is no storage location that is free of tradeoffs — there is only the one whose tradeoff you’ve consciously handled.

How a senior actually decides

Default to server sessions for first-party web apps: same origin, a browser that already does cookies well, and a hard requirement that “log out” and “ban” work now. The per-request lookup against Redis is cheap and buys you the revocation you’ll need the day something leaks. Reach for tokens when the shape demands statelessness — service-to-service calls, mobile and third-party API clients, or a fleet where no shared session store fits — and when you do, make them short-lived access tokens with server-side refresh, so the stateless part is bounded to minutes and the revocable part lives in the refresh token. The wrong answer is the middle: a long-lived JWT used as a de-facto session, which gives you a token’s revocation problem and a session’s blast radius at the same time.