Your API authenticates requests with stateless JWT access tokens that resource servers validate locally. Security asks you to support immediate logout and the ability to revoke a compromised token before it expires. Explain the tension here and how you'd design for it.

technical-conceptual · Senior level · software-engineering

What the interviewer is really asking

Assesses understanding of the fundamental trade-off between stateless JWT validation and revocation — whether the candidate sees that 'stateless' and 'instantly revocable' are in tension and can design a balanced solution (short TTLs, refresh-token rotation, a denylist) rather than ignoring one side.

What to say

• Name the core tension: a JWT is self-contained and validated locally, so by design nobody calls the issuer on each request — which is exactly why you can't instantly invalidate one without reintroducing some server-side state.
• Cover the standard mitigation: short access-token TTLs (minutes) plus refresh-token rotation so a compromised refresh token is single-use, bounding the exposure window without a lookup on every request.
• For true immediate revocation, describe a denylist (e.g. the token's jti in a fast store like Redis) checked per request, and be explicit that this trades away pure statelessness and adds a lookup — so you scope it to high-risk actions or accept the per-request cost deliberately.

What to avoid

• Insisting JWTs can be revoked 'just like sessions' with no architectural change, ignoring that local validation is the whole point of the design.
• Proposing very long-lived access tokens 'for convenience' — that maximizes the window an attacker can use a stolen token and is exactly what RFC 9700 warns against.
• Pretending there's a free lunch — claiming you can keep fully stateless validation AND instant global revocation with no added state, lookup, or TTL cost.

Example answers

Strong: The tension is that JWTs are validated locally precisely so we don't hit the issuer per request, which is the same reason there's no built-in 'revoke now.' My default is short access TTLs — say 5–15 minutes — with rotating refresh tokens, so a stolen access token dies fast and a stolen refresh token is single-use and detectable on reuse. When security genuinely needs instant kill, I add a jti denylist in Redis checked on each request, and I'm explicit that this trades pure statelessness for immediacy, so I'd apply it broadly only if the threat model justifies the lookup.

Weak: JWTs already support revocation — we just delete the token on the client when the user logs out, and we can set a long expiry so users don't have to log in often. If one is stolen we change the signing key.