JWT Token Replay
Token replay occurs when an attacker reuses a captured valid JWT to impersonate a user or service account. Because bearer JWTs authenticate whoever presents them, stolen tokens work until they expire unless additional controls exist at the server. Defenses include short access-token lifetimes, TLS everywhere, careful browser storage, rotating refresh tokens, and optional jti tracking for one-time use semantics where state is acceptable. Logging and anomaly detection help spot reuse from unusual networks or devices after theft. Replay is distinct from forgery: the signature verifies correctly; the problem is possession of a legitimate token by an unauthorized party who intercepted or exfiltrated it.
Why It Matters
Even perfect cryptography fails if tokens leak through XSS, application logs, or referrer headers on third-party navigations. Design for theft from day one: minimize lifetime, store tokens carefully, and prefer httpOnly cookies with CSRF defenses for browsers when that model fits. Security checklists should treat replay as a first-class threat alongside alg none bugs and weak HMAC secrets. Combine short exp, TLS everywhere, careful logging redaction, and optional jti denylists for high-value actions. Assume bearer tokens will leak eventually and design lifetimes and storage so stolen tokens expire before they become lasting account takeovers.
Related Terms
Related Comparisons
Related Tools
Related Articles
Frequently Asked Questions
Does exp stop all replay attacks?
No. Expiration only limits the useful window. Stolen tokens remain valid until exp unless you revoke them, rotate keys, bind them to a sender, or keep lifetimes very short.
How does jti help against replay?
jti gives each token a unique ID you can denylist after one-time use or after logout. It only helps if verifiers persist and check those IDs within the token lifetime.
Is refresh token theft a replay problem?
Yes. Stolen refresh tokens are long-lived replay material. Rotate refresh tokens, bind them to clients when possible, and revoke server-side on logout or anomaly detection.