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.
At a glance
What this is: This article explains how token replay attacks turn valid access or refresh tokens into reusable credentials after login.
Why it matters: IAM and security teams need to treat token handling as a lifecycle control problem, because MFA and SSO do not stop misuse once a token is stolen.
Context
Token replay attacks exploit a simple but overlooked condition in modern SaaS: once authentication succeeds, the token becomes the live credential. That shifts the real security boundary away from the login page and into token storage, token transport, and token reuse controls.
For identity governance, the issue is not whether MFA or SSO works at sign-in. The issue is whether the session token can be stolen, replayed, or silently refreshed without any native signal that the original subject is no longer in control.
Key questions
Q: What breaks when MFA is in place but token replay protection is missing?
A: MFA still verifies the initial login, but it does not stop a stolen access or refresh token from being reused later. The failure is that the token becomes a standalone credential after authentication, so whoever holds it can act as the user until expiry or revocation.
Q: Why are OAuth tokens such a persistent SaaS security risk?
A: OAuth tokens are persistent because they often bypass MFA, carry broad delegated permissions, and remain valid long after the original approval. That combination creates durable access for attackers if a token is stolen or abused. The problem is amplified when organisations lack full visibility into connected apps and do not review grants regularly.
Q: How should teams detect that a token is being misused after issuance?
A: Look for signals that do not match the original session context, such as impossible travel, device fingerprint mismatches, unexpected API velocity, parallel session use, and access to resources the user never touched before. Valid token status alone is not enough to prove legitimacy.
Q: What is the difference between refresh token rotation and short token lifetimes?
A: Short token lifetimes reduce the time a stolen token can be replayed, while refresh token rotation turns reuse itself into a detectable event. They solve different problems, so organisations need both: one limits exposure, the other exposes theft when a refresh token comes back twice.
Technical breakdown
Why bearer tokens are replayable
Bearer tokens work on possession, not identity continuity. If a server accepts a valid token, it assumes the presenter is the same subject that received it, so any interception point becomes an impersonation path. That includes network capture, browser storage, logs, and compromised integrations. The weakness is structural: the token authenticates the session once, then outlives the original login event unless additional binding exists.
Practical implication: treat bearer tokens as high-value credentials and reduce the places where they can be exposed or reused.
How refresh token reuse extends compromise
Refresh tokens are designed to mint new access tokens without forcing the user through login again, but that convenience becomes persistence when the token is stolen. If refresh token rotation is absent, a captured refresh token can remain usable long after the original access token expires. Rotation changes the control from passive expiry to active reuse detection, which is the difference between a temporary leak and a durable backdoor.
Practical implication: require refresh token rotation and revoke the entire token family on reuse.
Why DPoP changes the replay model
Demonstrating Proof-of-Possession, or DPoP, binds a token to a client-held key so possession of the token alone is not enough. The server checks both the token and a fresh proof signed by the corresponding private key on each request. That breaks simple replay because stealing the token no longer grants usable access. This is especially relevant for public clients that cannot safely rely on shared secrets.
Practical implication: use sender-constrained tokens where possible, especially for browser, mobile, and CLI clients.
Threat narrative
Attacker objective: The attacker wants to operate as a trusted user or integration long enough to access data, manipulate systems, or persist without reauthentication challenges.
- Entry begins when an attacker captures a valid access token or refresh token through interception, browser storage abuse, compromised integration access, or log exposure.
- Credential abuse follows when the attacker replays the token against the resource server and the server accepts it because the token is still valid and properly signed.
- Escalation occurs when the attacker uses the same identity context to call APIs, read data, modify records, or mint new access through refresh token reuse.
- Impact is sustained impersonation under a legitimate user or integration identity, often with little immediate visibility until abnormal volume or later forensic review.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Token replay is an after-login identity failure, not an authentication failure: MFA and SSO can prove the login ceremony, but they do not prove that the same subject still controls the token later. That distinction matters because the security boundary moves from human proofing to token governance the moment a bearer token is issued. Practitioners should stop treating post-login access as a solved problem once MFA is in place.
Token replay is a session governance problem because bearer semantics assume stable possession: The design premise is that whoever holds the token is authorised until expiry. That premise fails when tokens are copied, logged, proxied, or inherited through third-party integrations. The concept that emerges here is post-login trust decay: trust established at authentication weakens immediately after issuance unless the token is bound, rotated, or constrained.
Third-party integrations turn token replay into supply chain identity exposure: A compromised integration can inherit every token it holds, which means the trust boundary extends beyond the customer’s own IdP into partner-operated infrastructure. This is not a niche edge case. It is a structural reason why token inventory, token ownership, and integration scoping belong in identity governance, not just application security. Practitioners should map which integrations can mint or store tokens on their behalf.
Short-lived tokens reduce exposure, but they do not solve the core assumption problem: The article’s strongest point is that bearer tokens remain valid proof even after the original login context disappears. That is why refresh rotation, DPoP, PKCE, and behavioural detection matter together. The field should treat token replay as a control model problem: the control set must account for stolen credentials after authentication, not only failed login attempts.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
Post-login trust decay: Once a token is issued, the control problem shifts from proving who logged in to proving that the same subject still controls the token at every later use. Identity programmes that stop at MFA coverage are measuring the wrong boundary.
Bearer tokens reward convenience, but they also create a possession-based trust model that collapses when tokens are copied, logged, or inherited by third-party integrations. That makes token binding, rotation, and replay detection core governance controls rather than optional hardening.
Access review programmes do not solve token replay on their own because replay happens inside a live session, often before any periodic review cycle can react. The practical response is to move enforcement to issuance time and add context-aware detection after issuance.
For practitioners
- Audit token storage locations Review where access and refresh tokens are stored in browser, application, logging, and integration layers. Remove storage patterns that allow JavaScript, logs, or shared infrastructure to read reusable tokens.
- Enforce refresh token rotation Invalidate each refresh token on use and detect reuse as a compromise signal. Revoke the full token family when a replay attempt appears.
- Adopt sender-constrained tokens Use DPoP or certificate-bound tokens where client support allows it so a stolen token cannot be replayed without the related private key or certificate.
- Build replay detection signals Correlate impossible travel, device mismatch, parallel session use, and sudden API volume changes to identify valid tokens being misused after issuance.
- Inventory third-party token holders Document which integrations hold OAuth tokens, what scopes those tokens carry, and where those tokens are stored so revocation can follow the actual trust chain.
Key takeaways
- Token replay attacks exploit the gap between successful login and ongoing token control, which means MFA and SSO do not stop misuse once a token is stolen.
- The article describes replay through network interception, browser storage, logs, and compromised integrations, showing that the token lifecycle is the real exposure surface.
- Short-lived access tokens, refresh token rotation, sender-constrained tokens, and behavioural detection are the controls that actually reduce replay risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Token theft and exposure are the entry condition for replay attacks described in the article. |
| NHI-04 — Insecure Authentication | Bearer-token replay shows that authentication claims without proof of possession can be reused after login. | |
| NHI-07 — Long-Lived Secrets | Long-lived access and refresh tokens extend the replay window after compromise. | |
| Recommendation — Eliminate storage and logging paths that expose reusable tokens to interception or exfiltration. Bind tokens to the presenting client so possession alone is not sufficient for access. Shorten token lifetimes and rotate refresh tokens on every use to limit replay exposure. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifecycle control is directly analogous to authenticator issuance, rotation, and revocation. |
| Recommendation — Apply authenticator lifecycle controls to invalidate stolen or reused tokens quickly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Replay abuse bypasses the intended authorization boundary after the initial login. |
| Recommendation — Limit token scope and session duration so replayed tokens cannot retain broad standing access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes stolen tokens being reused to access APIs and pivot across environments. |
| Recommendation — Map replay indicators to credential access and lateral movement detections in your monitoring pipeline. | ||
Key terms
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
- Refresh token rotation: Refresh token rotation replaces a reusable refresh token with a new one each time it is used. This limits the value of token theft because a stolen token becomes useless after the legitimate exchange, assuming the implementation handles revocation and concurrency correctly.
- Sender-constrained token: A sender-constrained token is tied to a specific client or cryptographic proof, rather than being usable by anyone who steals it. This reduces replay risk and is especially important where tokens can reach automation, services, or agents with broad API access.
- Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org