Token replay attacks expose the limits of MFA and SSO

At a glance

What this is: This is an analysis of token replay attacks and the controls that reduce token theft, reuse, and post-login impersonation.

Why it matters: It matters because IAM teams must treat tokens as governed credentials across NHI, autonomous, and human identity programs, not as disposable implementation details.

By the numbers:

• A stolen access token with a 60-minute expiration gives the attacker 60 minutes of unrestricted access, regardless of how many MFA factors were required to issue it.
• Access tokens should aim for lifetimes between 5 and 15 minutes.
• The biggest SaaS breach of 2025 was driven by stolen OAuth tokens from a compromised third-party integration, not by phished credentials.

👉 Read WorkOS's analysis of token replay attacks and MFA limits

Context

Token replay is what happens when a valid access token or refresh token is intercepted and reused by someone other than the intended user. The primary keyword here is token replay attacks, and the important governance point is that authentication does not end at login once bearer tokens are in circulation.

For modern SaaS and federated identity estates, this creates a control gap between strong sign-in and weak post-authentication token handling. MFA reduces initial account takeover risk, but it does not prove who is presenting a token later in the session, which is why token lifecycle controls now sit inside the IAM perimeter.

Key questions

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. Replay risk falls when stolen tokens have less time to work and cannot be reused without the original cryptographic key. Also remove tokens from browser storage and monitor for anomalous reuse across integrations.

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. Once a token exists, it becomes a standalone credential that can be presented without the original user present. That is why session governance and token binding matter as much as initial sign-in strength.

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. Without rotation, the authorization server has no easy way to tell whether a refresh request is legitimate or a replay. That creates silent persistence that can last well beyond the original access token lifetime.

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.

Technical breakdown

Bearer tokens versus proof-of-possession tokens

Bearer tokens are usable by whoever holds them, which makes them simple to integrate and easy to replay. Proof-of-possession designs change that model by binding the token to a cryptographic key the attacker does not have. DPoP and certificate-bound tokens add a second factor at the protocol layer, not at the login screen. That means the server checks both the token and evidence that the presenting client still controls the bound key. In practice, this shifts the problem from token theft alone to token theft plus key theft, which is materially harder for attackers to combine.

Practical implication: prioritize sender-constrained tokens for public clients and high-value APIs.

Refresh token rotation and reuse detection

Refresh tokens are more dangerous than access tokens because they can mint new access tokens repeatedly. Rotation changes that by invalidating the old refresh token each time it is used and issuing a new one. If a stolen refresh token is replayed after the legitimate client already used it, the authorization server can detect reuse and revoke the token family. This is one of the few mechanisms that converts silent persistence into a detectable event. Without rotation, stolen refresh tokens behave like long-lived backdoors, especially in SaaS integrations that remain connected for months.

Practical implication: enforce single-use refresh token rotation everywhere it is supported.

Token storage and replay exposure points

Tokens are usually stolen before they are replayed. Common exposure points include browser storage such as localStorage, logs, URL parameters, insecure transport paths, and compromised third-party integrations that already hold OAuth grants. The attack does not require breaking encryption if the token is exposed in plaintext to JavaScript or to an upstream service. Once stolen, the replay succeeds because the resource server only validates that the token is still legitimate, not whether the original user is still the one presenting it. That is why storage location and integration inventory are identity controls, not just developer convenience decisions.

Practical implication: remove tokens from script-readable storage and inventory every third-party token holder.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Short-lived tokens reduce exposure, but they do not remove bearer risk. A five-minute token still behaves as a transferable credential, only inside a shorter attack window. The important point is not that lifespan is tuned correctly, but that the organisation has admitted the token can be stolen and replayed at all. The implication is that token lifetime is a containment control, not a trust model.

Third-party integrations are now part of the identity perimeter, not adjacent to it. The article's breach example shows how a compromised integration can inherit every token it stores and replay them at scale across downstream SaaS environments. That is a supply-chain identity failure, not just vendor risk. Teams that do not govern integration-issued tokens as first-class credentials are leaving their most reusable access path outside direct oversight.

Replay-resistant token design belongs in the same governance tier as MFA policy and session control. A mature IAM programme now has to align token binding, rotation, revocation, and anomaly detection under one operating model. OWASP NHI Top 10 and NIST CSF both point to the same conclusion: if the credential can be replayed, then the assurance model is incomplete. The practitioner task is to govern tokens as security artifacts with lifecycle, not as implementation afterthoughts.

From our research:

• 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.
• That same report found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, and the practical lesson is that discovery without revocation leaves replay conditions in place.

What this signals

Ephemeral tokens do not remove governance debt, they compress it. Teams that shorten access lifetimes still need revocation paths, storage controls, and integration inventory because replay risk simply moves into a smaller window. The most important shift is to govern token validity as an identity lifecycle issue, not a backend implementation detail, and to map that control set to the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0.

Replay-resistant session design will increasingly become a procurement and architecture requirement. As SaaS estates expand, buyers should expect proof-of-possession options, refresh-token reuse detection, and actionable session telemetry to appear in security reviews. Organisations that cannot answer where tokens are stored, who can replay them, and how they are revoked will keep discovering the gap only after an incident.

For practitioners

• 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.
• Inventory every third-party token holder List which integrations store OAuth tokens, what scopes they carry, and where those tokens are retained so compromise of one service does not become broad downstream replay.
• Tie replay detection to automatic revocation Use impossible travel, velocity spikes, and concurrent session divergence as triggers for instant token revocation and forced re-authentication before attacker access persists.

Key takeaways

• Token replay attacks exploit the gap between successful authentication and weak token governance, which leaves bearer credentials usable long after login.
• The evidence is clear that refresh tokens, third-party integrations, and browser storage are the highest-value replay paths, and MFA alone does not close them.
• Short token lifetimes, rotation, sender binding, and automated revocation are the controls that actually constrain replay blast radius.

Key terms

• Token Replay: Token replay is the reuse of a valid access token or refresh token by an attacker who intercepted it. The server accepts the token because it is technically legitimate, which makes replay a post-authentication impersonation problem rather than a password problem.
• Refresh Token Rotation: Refresh token rotation is a control in which each refresh token is single-use and replaced after use. If a stolen refresh token is presented again, the authorization server can detect reuse and revoke the token family, reducing the chance of long-lived silent access.
• Sender-Constrained Token: A sender-constrained token is bound to a specific client key or certificate so it cannot be used by anyone who merely possesses the token string. This turns token theft into a much harder attack because the adversary must also control the associated cryptographic proof.
• Token Family: A token family is the chain of access and refresh tokens that originate from one authenticated session. When reuse is detected, revoking the entire family allows defenders to cut off the attacker and the legitimate client together, which is why family tracking matters in replay defense.

Deepen your knowledge

Token replay defenses, session governance, and refresh token rotation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is rethinking how bearer tokens fit into identity governance, it is worth exploring.

This post draws on content published by WorkOS: Token replay attacks: What they are, why MFA won't save you, and how to defend against them. Read the original.