2026-09-12 · 6 min read · Rahul Chitturi
- jwt
- replay-prevention
- security
The JWT ID claim can identify a token, but merely checking that jti exists does not prevent replay. A verifier must define where the identifier is unique, store accepted one-time values atomically, and retain them for the entire acceptance window.
Not every access token is one-time-use. Apply replay caching only when the protocol or application contract requires it, because rejecting a second ordinary API call with the same bearer token would break normal usage.
Define the replay key and lifetime
Key the replay decision with enough trusted context to avoid collisions between issuers, tenants, token types, or purposes. Derive retention from validated expiration and allowed clock skew, with an operational cap for malformed or excessive dates.
- Verify signature, issuer, audience, and time claims first.
- Require a bounded jti syntax and length.
- Use issuer plus jti when identifiers are issuer-scoped.
- Do not log raw bearer tokens as replay evidence.
Make first use atomic
Two concurrent requests can both pass a read-then-write cache check. Use an atomic insert-if-absent operation with expiry, and decide whether cache unavailability fails closed, fails open, or follows a documented degraded policy.
Align cache partitioning, replication, and eviction with the security boundary. A per-instance memory set cannot protect requests routed to another process.
Test disposable token identities
Use the JWT decoder with synthetic tokens, timestamp converter for expiry windows, hash tool for public fixture labels, and diff for replay outcomes. Decoding alone does not authenticate a token.
Test simultaneous first use, duplicate jti values across issuers, missing and oversized identifiers, expiration boundaries, cache eviction, failover, clock skew, retries, multi-region routing, and both one-time and reusable token profiles.