Session Management, Refresh and Revocation

The previous lesson left a gap on purpose: a short-lived JWT is fast to verify and hard to revoke, which is exactly the trade-off you want for an access token but exactly the trade-off you cannot accept for the credential that keeps a user signed in over a session that might run for days. Something has to let a user stay authenticated across many requests without re-entering credentials every few minutes, and that same something has to be revocable the instant a session needs to end — on logout, on password change, or the moment a token is suspected stolen.

The answer nearly every mature API uses is a pair of tokens with different jobs and different lifetimes: a short-lived access token, the JWT from the previous lesson, presented on every request and never checked against a database; and a long-lived refresh token, checked against server-side state precisely because it needs to be revocable, exchanged periodically for a new access token. The access token is fast because it trusts a signature; the refresh token is safe because it doesn't have to be fast — it's used far less often, so a database lookup on every use is an acceptable, even necessary, cost.

This lesson is about the refresh side of that pair: how a refresh token should be issued, rotated, and revoked, and specifically the pattern of refresh token theft — an attacker obtaining a refresh token and using it to mint their own stream of access tokens long after the original session should have been unremarkable — and the rotation-plus-reuse-detection design that catches it.

None of what follows is exotic cryptography. It's bookkeeping: knowing which refresh token is currently valid for which session, rotating it on every use so a stolen-and-reused old token is detectable, and having a fast, reliable way to kill every session belonging to a user the moment that's necessary.

Analogy🏏Cricket

🏏 Think of it like cricket: A team's dressing-room access on a tour works on two different documents with two different jobs. The matchday accreditation pass gets a quick visual check at every door all day — a steward glances at the laminate and waves the holder through, because checking it against a master list every single time would make the whole ground grind to a halt. The tour management's actual master list, held by team security, is what that laminate was issued from in the first place, and it's checked properly only when something changes — a new pass is issued, someone's tour ends, or a lost pass is reported and needs cancelling. The laminate is fast because everyone trusts it was properly issued; the master list is where real control lives, because it's the only place a specific pass can actually be cancelled. An access token is the laminate, checked in an instant at every door. A refresh token is the master list entry behind it — slower to consult, but the only place a single compromised credential can actually be shut off without shutting off every laminate the ground has ever issued.