Token replay

What it means

Token replay is when an attacker takes a valid token, such as a session value or an access token, and presents it themselves. The server sees a token it issued, still in date, and treats the sender as the person it was issued to.

Most tokens are bearer tokens. The OAuth specification says that anyone who holds one can use it, with no proof of who they are. That is why the reuse works, and why where the token has been, and how long it lives, matter more than how it was made.

Why it matters

A replayed token passes every check, including multi-factor sign-in the user completed earlier. Nothing in the log looks odd except perhaps a new device or location. The attacker reads data and makes changes under a real identity, until the token expires or someone revokes it.

The business impact is therefore tied to token life. Long-lived tokens turn a brief leak, for example in a support ticket or an error report, into extended access. The replay attack family is wider, but this version is behind many cases of session hijacking.

How it shows up

Tokens leak through logs, URLs, browser history, analytics tools, error messages, malware, XSS, and a proxy or tool that records traffic. They are then replayed from another machine. Defences are short expiry, careful storage, revocation, and binding to the holder.

Sender-constrained tokens do the last part. DPoP, defined in RFC 9449, ties a token to a key held by the client, so a copy without the key is refused. Mutual TLS can do the same. The mistakes: tokens in query strings, long lifetimes, no revocation, and logs that store the Authorization header. Check each.