A JWT is stateless, so how do you revoke one before its exp time arrives?

## The problem stated precisely A signed token is a statement frozen at minting time: *this issuer asserted these claims and they hold until `exp`*. A verifier that checks only the signature and the claims is, by construction, unable to learn that anything changed afterwards — a user logged out, an employee was terminated, a token was stolen, a role was removed. That is the price paid for validating without calling the issuer. So the honest answer is never "you can revoke a JWT"; it is "you reintroduce exactly as much state as your revocation requirement demands, and no more". ## Mechanism 1 — short lifetimes plus a revocable refresh token The standard shape. The access token presented to services is deliberately short-lived (commonly a few minutes). A separate refresh token, held by the client and *recorded in the issuer's storage*, is exchanged for new access tokens. Revocation becomes a database delete at the issuer: the refresh token stops working immediately, and the last outstanding access token dies naturally at its `exp`. This keeps resource servers completely stateless — they still just verify and check claims — and moves all state to one place that already has a database. The cost is a bounded window: a stolen access token remains usable for up to its remaining lifetime. Shrinking the TTL shrinks the window but increases refresh traffic against the issuer, so the TTL is a tuning dial between revocation latency and issuer load. Refresh-token rotation strengthens this: each refresh issues a new refresh token and invalidates the old one, so replay of a stolen refresh token collides with the legitimate client's use and can be detected as reuse, triggering invalidation of the whole chain. ## Mechanism 2 — a jti denylist Give every token a `jti`, a unique identifier, and have verifiers consult a shared store of revoked identifiers as part of validation. Revoking a specific token is then a write to that store. The practical points that separate a good answer from a hand-wave: - **The store is bounded.** An entry only has to survive until the token's own `exp`, so entries carry a TTL and the set stays proportional to *revoked tokens still within their lifetime*, not to all tokens ever issued. - **It is a lookup on the hot path.** Every request now depends on a cache or store, so latency and availability of that store become authentication concerns. Deployments typically use an in-memory data store with local caching and short TTLs. - **Fail-closed or fail-open is a real decision.** If the denylist is unreachable, accepting tokens keeps the service up but temporarily un-revokes everything; rejecting them fails securely but converts a cache outage into an outage. For most systems, high-value operations fail closed and read-only paths may fail open — but that must be a decision, not an accident. A denylist is precise (kill one token) which makes it the right tool for "this device was lost" and the wrong tool for "disable this account". ## Mechanism 3 — a per-principal cutoff Store, per user, a timestamp such as `tokensValidAfter`, updated whenever their credentials or status change. Validation compares the token's `iat` against that value and rejects anything issued earlier. One write invalidates every outstanding token for that user — logout-everywhere, password change, account disable, role revocation — without tracking individual tokens. The lookup is per user rather than per token, which caches well, and the stored data is one small field per principal. The limitation is granularity: it cannot revoke one session while leaving another alive, so it complements rather than replaces a denylist. ## Mechanism 4 — key rotation as break-glass Retiring a signing key invalidates every token signed with it, everywhere, instantly. That is the correct response to a suspected key compromise and a terrible response to one user's logout: every active session in the system ends at once. Keep it in the runbook, not in the request path. ## Choosing, and defending the choice Start from the requirement: *how quickly must access actually stop?* If the answer is "within a few minutes", short lifetimes alone satisfy it, and you keep full statelessness. If the answer is "immediately, for high-value operations", you need a lookup, and the cheapest sufficient one is usually the per-user cutoff, with a `jti` denylist added when individual-session revocation is genuinely required. Be explicit about what you have given up: every revocation mechanism is state on the verification path, which is precisely the property that made the token attractive. A design that claims both perfect statelessness and immediate revocation is describing something else. ## Related failure to name Authorization changes have the same shape as revocation. A role removed at 10:00 is still asserted by a token minted at 09:58, so permissions-in-the-token are permissions-as-of-issue-time. Systems that need instant permission changes either keep lifetimes very short or look up authorization data at request time rather than trusting claims.