Token replay attacks: What they are, why MFA won't save you, and how to defend against them

For years, the security industry focused on protecting credentials. Passwords got longer, MFA became standard, and SSO centralized the login experience. These were meaningful improvements. But they all share the same blind spot: they protect the front door of authentication while leaving the artifacts of a successful login, tokens, dangerously exposed.

A token replay attack occurs when an attacker intercepts a valid access token or refresh token and reuses it to impersonate a legitimate user. The attacker never needs to know the user's password. They never need to pass an MFA challenge. The token itself is proof of authentication, and once it's in someone else's hands, the system has no native mechanism to tell the difference between the real user and the attacker.

This isn't a theoretical concern. The biggest SaaS breach of 2025 was driven by stolen OAuth tokens from a compromised third-party integration, not by phished credentials. Attackers replayed those tokens across hundreds of downstream environments, bypassing every SSO and MFA control in place.

How token replay attacks work

The mechanics are deceptively simple. An attacker needs two things: a valid token and the ability to present it to a server that accepts it.

Step 1: Token capture

Tokens get stolen through a variety of vectors:

• ‍Network interception. Despite widespread TLS adoption, misconfigurations, legacy endpoints, and adversary-in-the-middle attacks on untrusted networks can expose tokens in transit. The Authorization: Bearer <token> header is plaintext once TLS is stripped.‍
• Malware and browser extensions. Developers commonly store tokens in localStorage or sessionStorage for convenience. Any JavaScript running in the same origin, including a malicious browser extension, can read and exfiltrate these values. A browser extension with broad permissions doesn't need to break any encryption. It just reads the storage.‍
• Compromised third-party integrations. In modern SaaS environments, OAuth tokens frequently pass between services. When a third-party integration is breached, the attacker inherits every token that integration holds. This is supply chain risk applied to identity.‍
• Log exposure. Tokens accidentally written to server logs, error tracking systems, or URL query parameters become discoverable to anyone with access to those systems.

Step 2: Token replay

With a valid token in hand, the attacker simply presents it to the resource server. The server validates the token (checking signature, expiration, scopes) and grants access. Every check passes, because the token is legitimate. It was issued by a real authorization server for a real user. The server has no reason to reject it.

The attacker can then access APIs, read data, modify resources, or pivot laterally, all under the identity of the compromised user.

Why MFA and SSO don't help

This is the critical point that many security teams miss: MFA and SSO protect the authentication ceremony. Token replay attacks occur after authentication has already succeeded.

Think of it this way. MFA ensures that the person logging in is who they claim to be. But once they've logged in and received a token, that token becomes a standalone credential. It carries no ongoing proof that the person presenting it is the same person who completed the MFA challenge.

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. A stolen refresh token can be even more dangerous. It can be used to silently mint new access tokens, potentially maintaining access for days or weeks.

The anatomy of a real-world token replay

Here's a concrete scenario that illustrates how these attacks unfold in production.

An enterprise uses an identity provider for SSO across its SaaS stack. One of its approved third-party integrations, a sales engagement tool, connects to the company's CRM via OAuth. The integration stores refresh tokens to maintain its connection.

An attacker compromises the third-party vendor. They now have access to stored OAuth tokens for every customer of that vendor. They begin replaying those tokens against the CRM's API, pulling contact records, deal data, and internal notes. The requests look identical to normal integration traffic: valid tokens, expected scopes, familiar IP ranges (since they're coming from the vendor's infrastructure).

No alert fires. The data exfiltration continues until someone notices anomalous query volume or, more commonly, until the breach is discovered months later.

Defense in depth: stopping token replay

There is no single mechanism that eliminates token replay. The effective strategy is layered, combining token design, protocol-level protections, and behavioral detection.

1. Keep token lifetimes short

The simplest mitigation is also the most impactful. A token that expires in 5 minutes can only be replayed for 5 minutes. This doesn't prevent replay, but it drastically reduces the window of opportunity.

For access tokens, aim for lifetimes between 5 and 15 minutes. Use refresh tokens to avoid forcing users through repeated authentication, but make sure those refresh tokens are rotated on every use (more on that below).

2. Implement refresh token rotation

With refresh token rotation, each time a refresh token is used to obtain a new access token, the old refresh token is invalidated and a new one is issued. If an attacker replays a stolen refresh token after the legitimate client has already used it, the authorization server detects the reuse and can revoke the entire token family.

This transforms a stolen refresh token from a persistent backdoor into a detectable event.

3. Adopt sender-constrained tokens with DPoP

Demonstrating Proof-of-Possession (DPoP), defined in RFC 9449, is the most significant protocol-level defense against token replay. Instead of treating tokens as bearer instruments that are usable by anyone who holds them, DPoP binds tokens to a cryptographic key pair controlled by the client.

Here's how it works: the client generates a public/private key pair and includes the public key in a signed JWT (the "DPoP proof") when requesting tokens. The authorization server binds the issued token to that public key. On every subsequent API call, the client must present both the token and a fresh DPoP proof signed with the corresponding private key.

If an attacker steals the token but doesn't have the private key, the token is useless. The resource server will reject the request because the attacker can't produce a valid DPoP proof.

DPoP is particularly valuable for public clients like browser-based SPAs, mobile apps, and CLI tools that can't securely store client secrets. For environments that support mutual TLS, certificate-bound tokens (RFC 8705) provide an even stronger guarantee at the transport layer.

4. Enforce PKCE for all OAuth flows

Proof Key for Code Exchange (PKCE) prevents authorization code interception, which is a common precursor to token theft. PKCE ensures that the entity exchanging an authorization code for tokens is the same entity that initiated the flow, by requiring a cryptographic verifier that only the original client possesses.

OAuth 2.1 makes PKCE mandatory for all clients, not just public ones. If your authorization server supports it, enforce it everywhere.

5. Bind tokens to context

Beyond cryptographic binding, tokens can be associated with contextual signals: device fingerprints, IP addresses, geographic locations, or client certificates. If a token is suddenly presented from a different device, network, or country, the resource server can challenge or reject the request.

This isn't foolproof. Sophisticated attackers can proxy their traffic through the expected geography. But it raises the cost of exploitation significantly.

6. Deploy behavioral detection

The last line of defense is anomaly detection. Because replayed tokens are technically valid, you need signals beyond token validity to identify misuse:

• ‍Impossible travel. If a token is used from New York at 2:00 PM and from Singapore at 2:05 PM, something is wrong.‍
• Velocity anomalies. A sudden spike in API calls, bulk data exports, or access to resources the user has never touched before should trigger investigation.‍
• Device fingerprint mismatches. If the token was issued on a macOS device and is now being used from a Linux server, that's a strong signal.‍
• Session divergence. If the legitimate user and the attacker are both using the same token concurrently, detecting parallel sessions can surface the compromise.

7. Build automated revocation workflows

Detection is only useful if you can act on it. Build workflows that can automatically revoke suspicious tokens, terminate sessions, and force re-authentication, ideally within minutes of detection, not hours.

What this means for developers building on OAuth

If you're building applications that use OAuth for authentication and authorization, token replay is your problem whether you think about it or not. Here's the practical checklist:

• ‍Audit your token storage. If you're storing tokens in localStorage, you're one malicious browser extension away from a breach. Consider using httpOnly cookies, secure session storage, or service workers to isolate tokens from JavaScript.‍
• Enforce short-lived access tokens. Don't set token lifetimes based on convenience. Set them based on how long you'd be comfortable with an attacker having access if a token leaked.‍
• Rotate refresh tokens. Every single use. No exceptions.‍
• Evaluate DPoP. If your identity provider supports DPoP, adopt it, especially for public clients. It's the strongest application-layer defense against token replay currently available.‍
• Require PKCE. For every OAuth flow, for every client type. There's no reason not to in 2026.‍
• Monitor for anomalies. Even with perfect token hygiene, assume that tokens will eventually leak. Build the observability to detect and respond when they do.‍
• Inventory your third-party integrations. Know which OAuth tokens each integration holds, what scopes those tokens carry, and where they're stored. Your security posture is only as strong as your weakest integration.

Tokens are the new perimeter

Token replay attacks exploit the gap between strong authentication and weak token management. Closing that gap requires treating tokens not as implementation details but as first-class security artifacts, with lifetimes, binding, rotation, and monitoring designed from the start.

This is how we think about it at WorkOS. Short-lived sessions, enforced PKCE, and the ability to revoke sessions instantly across every device aren't optional add-ons in our authentication stack. They're defaults, because the right time to get token hygiene right is before your customers have to think about it.

The organizations that get this right will be the ones that stop thinking about security as something that happens at the login page, and start thinking about it as something that persists for the entire lifecycle of a session.