Revoking stateless JWTs on logout

WHAT THIS TESTS Whether you understand that a self-contained JWT is valid until it expires, so genuine logout or revocation must reintroduce server-side state. The interviewer wants the trade-off between statelessness and security.

A GOOD ANSWER COVERS Strategy one, a denylist. When a user logs out you store the token's unique jti claim in a fast store like Redis with a TTL equal to the token's remaining lifetime. Every protected request checks the denylist before trusting the token. This gives immediate revocation but adds a store lookup per request and partially sacrifices the stateless property that made JWTs attractive. Strategy two, short access plus refresh tokens. Issue access tokens with a short lifetime such as a few minutes, and a longer-lived refresh token stored and tracked server-side. Logout deletes or marks the refresh token revoked; the access token cannot be refreshed and expires quickly on its own. This keeps access-token validation stateless while concentrating revocation logic on the much rarer refresh path.

COMMON WRONG ANSWERS Claiming you can revoke a JWT with no server state at all. Saying that clearing the token from localStorage logs the user out, ignoring that a copied token still validates. Setting access-token lifetime to hours while expecting instant logout.

LIKELY FOLLOW-UPS What is the jti claim? How do you size the denylist TTL? How do you handle revoking all sessions for a compromised account?

ONE CONCRETE EXAMPLE A banking app issues 5-minute access tokens and 7-day refresh tokens. On logout, the server deletes the refresh token row. The current access token still works for up to 5 minutes, which is acceptable, and the user cannot obtain a new one. For high security it also denylists the access token's jti in Redis with a 5-minute TTL so the cutoff is immediate.