Sessions vs JWT, and why logout is hard

Two models: where the auth state lives

Before you can pick an auth model or debug a logout that “didn’t work,” you need to understand one thing: where does the server keep the truth about who you are? The answer to that question dictates everything else — what revocation costs, how many round-trips a request takes, and whether “ban this user now” is a one-liner or an architectural problem. Every auth scheme answers one question on each request — “is this caller who they claim to be?” — and the two dominant models answer it from opposite places.

Stateful server sessions keep the truth on the server. Login creates a session row in a store (Redis or a DB table); the client gets back only an opaque, meaningless session id in an httpOnly cookie. Every subsequent request carries that id, and the server looks the session up to learn who you are.

// Stateful: the cookie holds an opaque id; the server holds the truth.
// Login writes a row; every request reads it back.
await store.set(`sess:${sid}`, { userId, roles }, { ttlSec: 3600 });
res.cookie('sid', sid, { httpOnly: true, secure: true, sameSite: 'lax' });

// On each request, a guard resolves identity by LOOKING IT UP:
const session = await store.get(`sess:${req.cookies.sid}`); // 1 store read
if (!session) throw new UnauthorizedException();             // revoked → instantly out

Stateless JWT keeps the truth in the token. The token is the claims (sub, roles, exp), signed by the server. Verification is local: check the signature and exp, trust the payload. No store, no lookup.

// Stateless: the token carries the claims, signed. Verify is local — zero lookups.
const token = jwt.sign({ sub: userId, roles }, SECRET, { expiresIn: '15m' });

// On each request: verify signature + exp, then trust the payload. No I/O.
const claims = jwt.verify(req.headers.authorization?.slice(7), SECRET);

The difference is the whole lesson. Sessions cost one store read per request and force you to share that store across every app instance (sticky sessions, or a central Redis — shared state is the price). JWT costs zero lookups and scales horizontally with nothing shared — which is exactly why it cannot be revoked: there is no row to delete.

The logout problem: trivial with sessions, hard with JWT

“Log this user out everywhere” / “ban this account NOW” is the same operation, and it exposes the asymmetry brutally.

With sessions it is one line: delete the row. The next request’s lookup misses, the guard throws, and the user is out — on every device, instantly, globally. The server held the state, so the server can destroy it.

// Sessions: revocation IS deletion. Instant, global, done.
await store.del(`sess:${sid}`);        // one device
await store.del(`user-sessions:${userId}`); // or every device — next lookup misses

With JWT there is no such line. The token is self-validating: any holder of the bytes is authenticated until exp, full stop. You can clear the cookie — but that only affects a cooperating client. A token copied by a thief, or replayed by the abuser’s script, is untouched. There is no server-side handle to pull.

So you simulate revocation, and every option is a tradeoff:

// (1) SHORT access-token TTL — shrink the un-revocable window to minutes.
//     This is why refresh tokens exist (covered separately): exp does the revoking.
jwt.sign({ sub: userId }, SECRET, { expiresIn: '15m' }); // window ≤ 15 min

// (2) DENYLIST revoked jti until their exp — but this is a per-request lookup again,
//     reintroducing the shared state you adopted JWT to escape. A hybrid.
if (await denylist.has(claims.jti)) throw new UnauthorizedException(); // +1 read

// (3) PER-USER tokenVersion (a.k.a. minIssuedAt) — bump it on logout-all /
//     password-change; reject any token issued before. One indexed lookup,
//     invalidates ALL of a user's tokens at once. The pragmatic middle ground.
const u = await users.findById(claims.sub);               // 1 indexed read
if (claims.tokenVersion !== u.tokenVersion) throw new UnauthorizedException();

Option (1) caps the damage window but never closes it on demand. Option (2) gives precise per-token revocation but pays back the per-request read you went stateless to avoid. Option (3) is the one most teams land on: a single indexed column, bumped once, kills every token a user holds — the right tool for “ban now” and “log out all devices.”

Where each model fits — and why real systems are hybrid

Reach for sessions when instant global revocation is a hard requirement and a shared store is acceptable: classic server-rendered web apps, banking, admin consoles — anywhere “kill this access right now” must be true the next millisecond. Reach for JWT when a central session store is the bottleneck: stateless microservices, mobile/API clients, and cross-service auth where every hop revalidating against one Redis would serialize your fan-out.

Most mature systems refuse the binary and go hybrid: a short-lived stateless access JWT (zero lookups on the hot path) paired with a stateful refresh token stored in the DB (revocable). You already hold server-side state at the refresh boundary, so revoking the refresh token stops new access tokens from being minted — and the short access TTL drains the ones already out. That is the architecture that gets you JWT’s scale and sessions’ revocability, with the un-revocable window bounded to the access TTL.

A few JWT footguns ride along regardless. Token size: a JWT in a header or cookie is far larger than an opaque session id and rides on every request — keep claims minimal, never stuff a user’s whole profile in. Clock skew: exp is compared against each server’s clock, so allow a small leeway (a few seconds) or a node with a fast clock will reject still-valid tokens. Cookie flags matter for both models: httpOnly keeps JS from reading the token, Secure keeps it off plaintext, SameSite blunts CSRF.