Strategies for revoking stateless JWTs

WHAT THIS TESTS Whether you understand the fundamental tension: a self-contained signed token is valid until expiry, so revocation requires reintroducing some state or shrinking the validity window.

A GOOD ANSWER COVERS Strategy one is short-lived access tokens plus refresh tokens. Access tokens live only minutes, and a separate long-lived refresh token is stored server-side. On logout or password change you invalidate the refresh token, so once the short access token expires the user cannot get a new one. Trade-off: simple and mostly stateless, but the already-issued access token stays valid for its short remaining lifetime, leaving a brief window. Strategy two is a denylist (blocklist): you store the jti or a user-version of revoked tokens in a fast store like Redis and check every incoming token against it. Trade-off: revocation is immediate, but you have reintroduced a per-request stateful lookup, partly defeating the statelessness benefit. A variant is a per-user token version stamped in the token and compared to the DB.

COMMON WRONG ANSWERS Claiming you can delete a JWT server-side, ignoring the revocation window of short-lived tokens, or presenting a denylist as free of cost.

LIKELY FOLLOW-UPS Where to store the denylist, refresh-token rotation and reuse detection, choosing the access-token TTL, and password-change invalidation via token versioning.

ONE CONCRETE EXAMPLE With 5-minute access tokens, deleting a user's refresh token on logout means they are fully locked out within five minutes but their current access token still works briefly. Adding a Redis denylist keyed by jti, checked in the auth middleware, closes that window at the cost of a Redis read on every request.