A signed JWT can carry claims that a service checks without fetching a session record. That convenience does not answer a separate question: how quickly must an already issued token stop working?
Define the required revocation behavior before choosing storage. “Log out this browser,” “disable every session for this account,” and “stop accepting a stolen token now” are different operations.
Validate Before Using Claims
Decoding a token only reads its contents. Before trusting its subject, issuer, audience or token identifier, use a maintained verification library with an explicit algorithm and key policy. Validate the claims required by the application’s token profile, including time limits and the intended recipient. RFC 8725 covers JWT validation practices.
A revocation endpoint also needs authorization. A token containing somebody else’s identifier must not let the caller alter that person’s session state.
JWT is a format; it does not require every application to use the same session architecture.
Choose the State Boundary
| Approach | What the service checks | Main tradeoff |
|---|---|---|
| Short-lived access token | Signature and required claims | Existing tokens can remain usable until expiry |
| Session record | Current session status | Storage availability and cache freshness affect requests |
| Token denylist | Whether the validated token ID is revoked | Every enforcing service needs current revocation information |
| Account token version | Token version against current account version | Revokes a group of sessions rather than one token |
Deleting a refresh token prevents further refresh through that token, but does not automatically invalidate every access token already issued. OAuth revocation behavior depends on the token and authorization-server design; related tokens and propagation need deliberate handling. RFC 7009 describes the revocation protocol and these considerations.
A ten-minute access-token lifetime is an example policy, not a universal recommendation for most applications. Choose the window from the risk and user experience.
Rotate Refresh Tokens Atomically
Refresh rotation replaces the refresh credential after use and retains enough relationship information to detect reuse. Consumption and replacement need an atomic operation; two simultaneous refresh requests must not silently create unrelated valid successors.
OAuth’s current security guidance requires public-client refresh tokens to be sender-constrained or use rotation. RFC 9700 explains the replay-detection approach.
Decide how concurrent tabs and interrupted responses behave. A response lost after the server consumes a refresh token can resemble reuse on the next attempt. Use the provider’s supported behavior rather than inventing an unbounded grace period.
Make Denylist Semantics Explicit
Use an identifier scoped to the trusted issuer and token type. Retain a revocation record until the service can no longer accept that token, accounting for the verifier’s permitted clock tolerance. A premature TTL expiry can reopen the acceptance window.
If the store is unavailable, silently accepting a token would weaken a requirement for immediate revocation. Define an explicit policy: return a temporary failure, require reauthentication, or use another independently justified control. Measure the latency and availability cost; do not assume a network lookup is free.
A Bloom filter can reduce some membership checks, but positive matches require an exact lookup when false rejection is unacceptable. A freshly correct filter also differs from a stale replica missing recent revocations. Redis’s session-store discussion describes the probabilistic tradeoff; synchronization remains an application responsibility.
A Practical Acceptance Test
Issue a token, verify an allowed operation, revoke the intended session, and retry against every enforcing service. Repeat with a warm cache, a restarted instance and an unavailable revocation store. Test the boundary near expiry and exercise two simultaneous refresh attempts.
The result should state exactly which tokens stop working, where enforcement occurs and how quickly the change becomes effective. That is more useful than calling the architecture stateless while hiding its revocation dependencies.
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
