Notifications
Clear all
Topic starter
06/06/2026 11:18 am
TL;DR: Token replay attacks let attackers reuse valid access or refresh tokens to impersonate users, bypassing passwords, MFA, and SSO because the token itself becomes the credential, according to WorkOS. MFA proves the login ceremony, but token-based access assumes the authenticating subject stays the same for the full session, which is no longer a safe assumption.
NHIMG editorial — based on content published by WorkOS: Token replay attacks: What they are, why MFA won't save you, and how to defend against them
By the numbers:
- Access tokens should aim for lifetimes between 5 and 15 minutes.
Questions worth separating out
Q: How should security teams reduce token replay risk in SaaS environments?
A: Focus on shortening token lifetime, rotating refresh tokens on every use, and binding tokens to the client where possible.
Q: Why do MFA and SSO not stop token replay attacks?
A: MFA and SSO verify the login ceremony, but token replay happens after authentication has already succeeded.
Q: What breaks when refresh tokens are not rotated?
A: A stolen refresh token can keep minting new access tokens, which turns one compromise into persistent access.
Practitioner guidance
- Shorten access token lifetimes Set access token expiry based on acceptable blast radius, not convenience, and review whether 5 to 15 minute lifetimes are viable for your highest-value SaaS and API flows.
- Rotate refresh tokens on every use Enable single-use refresh token rotation so reused tokens can be detected and the full token family can be revoked when replay is observed.
- Move tokens out of script-readable storage Eliminate localStorage for sensitive tokens where possible and prefer httpOnly cookies, secure session isolation, or service-worker patterns that reduce exposure to browser-side theft.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on configuring short-lived access tokens across OAuth flows
- Implementation detail for refresh token rotation and reuse detection in production
- Protocol-level comparison of DPoP, mTLS-bound tokens, and PKCE enforcement
- Developer-focused storage patterns for reducing token exposure in browser-based apps
👉 Read WorkOS's analysis of token replay attacks and MFA limits →
Token replay attacks and the governance gap after login?
Explore further
06/06/2026 12:00 pm
Token replay is not a login problem, it is a post-authentication identity problem. MFA and SSO harden the front door, but bearer tokens move trust into a reusable artifact that can outlive the original session context. That means the control objective shifts from proving the user once to governing what can safely remain valid after that proof has already happened. Practitioners should treat token issuance, storage, replay, and revocation as one continuous identity control surface.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up.
A question worth separating out:
Q: Who is accountable when replayed tokens come from a compromised third-party integration?
A: The organisation remains accountable for the access it grants through its identity stack, even when the compromise starts with a vendor integration. Governance needs to cover token scope, storage, revocation, and offboarding for every external service that can hold credentials on the organisation's behalf.
👉 Read our full editorial: Token replay attacks expose the limits of MFA and SSO
