Token Replay
A captured bearer token is reused by an attacker — because possession is proof.
By the end of this lesson, explain why bearer tokens are replayable and how proof-of-possession stops it.
A bearer token means whoever bears it may use it — like cash. That's convenient and dangerous: if an attacker captures the token (from logs, a proxy, XSS, a leaked backup), they can replay it and be indistinguishable from the legitimate holder until it expires or is revoked.
Capture and replay
- An attacker captures a bearer token and replays it; the API sees a valid token and grants access.
flowchart LR token[Bearer token] -->|captured| attacker[Attacker] attacker -->|replays same token| api[API] api -->|valid signature| grant[Access granted]
The structural fix is sender-constrained (proof-of-possession) tokens: bind the token to a key the client must prove it holds on each call. mTLS-bound tokens and DPoP (a per-request signature) mean a stolen token is useless without the private key. Short TTLs, aud/exp checks, TLS everywhere, and keeping tokens out of URLs and logs reduce the window.
Token replay
- Trigger
- A bearer token is captured and re-sent by an attacker.
- Symptom
- Unauthorized access that looks identical to the legitimate user.
- Blast radius
- Everything the token authorizes, for its remaining lifetime.
- Mitigation
- Sender-constrained tokens (mTLS/DPoP), short TTLs, TLS, no tokens in URLs/logs, revocation.
How does DPoP make a stolen token useless?
The token is bound to a client key; each request carries a fresh signature proving possession of that key, which the attacker doesn't have.