hard Token Revocation and Refresh Rotation

Token Revocation & Refresh-Token Rotation at the Edge

Validating JWTs at the edge, locally (verify the signature against cached JWKS, no network call) is what makes a gateway fast — but it creates one hard problem: a locally-validated token is trusted until it expires, so the edge cannot know a token was revoked (logout, compromise, role change). The mechanism that resolves this is not "check every token against a server" (that throws away the speed win) — it is short-lived access tokens + a rotating refresh token, so revocation is enforced at the one place a network check is acceptable: the refresh.

How revocation actually propagates

• Short-lived access token (e.g. TTL ≤ 5 min), validated locally at the edge. Its TTL is the revocation window: a revoked user keeps access for at most the remaining TTL.
• Long-lived refresh token, presented only to the authorization server to mint a new access token. That call is the choke point where the server checks "is this session still valid?" — so revocation takes effect within one access-token TTL, without a per-request server call.
• Instant-revocation option: push a deny-list (revoked token IDs / user IDs) to the edge nodes. This gives immediate revocation but reintroduces shared state and a lookup on the hot path — use it only for high-value sessions where ≤TTL delay is unacceptable.

Refresh-token rotation + reuse detection

A long-lived refresh token is a juicy theft target, so the modern pattern is: rotate it on every use. Each time a refresh token RT_n is redeemed, the server issues a new access token and a new refresh token RT_(n+1), and invalidates RT_n. Because a valid refresh token is now single-use, seeing an already-used refresh token again means it was stolen (the attacker and the legit client now hold copies). The server's response is to revoke the entire token family — every token descended from that session — logging out both parties. Losing the legit user's session is the correct, safe default when theft is detected.

Traced example

1. Login → access AT (5 min) + refresh RT_1.
2. RT_1 redeemed → issue AT + RT_2; mark RT_1 used.
3. RT_2 redeemed → issue AT + RT_3.
4. Attacker replays the stolen RT_1 → server sees a used token reused → revoke the whole family (RT_1..RT_3). Both sessions die; the user re-authenticates.

Selection & trade-offs

• Local edge validation + short TTL (default): fast, no per-request authz call; revocation delayed by ≤ the TTL. Alternative: opaque tokens + introspection (edge calls the authz server every request) — instant revocation, but a network hop + load on every request. Choose local JWTs for scale, introspection only when zero revocation delay is mandatory.
• Refresh rotation vs a static long-lived refresh token: rotation gives theft detection at the cost of storing per-session token state; a static refresh token is simpler but a stolen one is usable until it expires with no detection.
• Deny-list push to edge vs relying on TTL: instant revocation vs no shared edge state — the classic latency/consistency-vs-simplicity call.

Pitfalls

• Long access-token TTLs (hours) — the revocation window becomes hours; keep access TTL small.
• Rotating refresh tokens but not detecting reuse — you get churn without the security benefit.
• On reuse detection, revoking only the presented token, not the family — the attacker keeps their branch.
• Storing the deny-list only centrally but claiming "edge revocation" — the edge still needs the pushed copy.

Takeaways

• Local JWT validation can't see revocation; short access TTL makes the TTL the revocation window.
• The refresh call is the enforcement choke point — no per-request server check needed.
• Rotate refresh tokens on use; a reused (old) one means theft → revoke the whole family.
• Deny-list push buys instant revocation at the cost of edge shared state + a hot-path lookup.

---

Re-authored and deepened for this guide, per the OAuth 2.0 Security BCP (draft-ietf-oauth-security-topics) for refresh-token rotation / reuse-detection, and RFC 6749 for the base flow and edge JWT-validation patterns. Re-authored/Deepened for this guide.

I just read a lesson on **Token Revocation and Refresh Rotation** (System Design) and want to truly understand it. Explain Token Revocation and Refresh Rotation from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Token Revocation and Refresh Rotation** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Token Revocation and Refresh Rotation** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Token Revocation and Refresh Rotation** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.