TRACK: THREATS AND DETECTION

Token theft, replay and forgery

Editorial assessment · Desk research from public vendor material · Reviewed 2026-09-29

3 min read

Strong sign-in protects the moment of authentication. What happens next is carried by a token: a session cookie in the browser, an OAuth access token for an API, a SAML assertion or an OpenID Connect ID token for an application. In the ordinary case each is a bearer credential, which means whoever holds it is treated as the person it was issued to.

Three ways tokens are abused

Theft

The attacker copies a valid token or session cookie, for example through adversary-in-the-middle phishing or malware on a device, and uses it before it expires.

Replay

The attacker reuses a token somewhere it should not work, or after the situation has changed, such as a new location or a device that no longer passes its checks.

Forgery

The attacker creates a token from nothing by obtaining the key that signs tokens. Golden SAML is the best-known case: with a federation service's signing key, an attacker can sign assertions for any user, and applications accept them as genuine.

What NIST IR 8587 covers

NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, was published as final on 15 September 2026, after a draft on 22 December 2025. It gives recommendations for identity providers, authorization servers, key management and token verification. The OpenID Foundation noted that it recommends two of its specifications: the Shared Signals Framework, which defines how identity providers and relying parties exchange security event signals, and the Continuous Access Evaluation Profile, which lets access be re-evaluated continuously rather than only at sign-in.

Controls the vendors describe

• Short token lifetimes. The MCP authorization specification says authorization servers should issue short-lived access tokens.
• Re-checking risk during a session. Okta Identity Threat Protection continuously assesses user risk, names session hijacking and token theft among its detections, and can end sessions across supported apps with Universal Logout.
• Tokens bound to one audience. MCP servers must check that a token was issued for them and reject any other.
• Protecting the signing key. NewCore's Secure Split Key needs a key share held in the customer's environment to sign any token, so a compromise of NewCore's cloud exposes only one share.

Questions to ask any identity provider

1. How long do sessions and tokens last by default, and can I shorten them?
2. What happens to active sessions when risk changes?
3. Does the product send or receive shared security signals?
4. Where is the token-signing key held, and who can use it?

See ITDR solutions compared