Token and Session Security: JWTs, Cookies and Theft

Every successful sign-in produces something an attacker would rather have than a password: a token or session cookie that is already authenticated. Access tokens, refresh tokens, JWTs and session cookies let users and services keep working without re-authenticating, and whoever holds them usually gets the same access, MFA included. Infostealers harvest browser cookies, appliance flaws leak live sessions, and SaaS vendors hold refresh tokens for thousands of customers. This guide explains the tokens and sessions identity teams need to protect, how they are stolen and replayed, and the lifetime, validation, binding and revocation controls that limit the damage.

Key takeaways

A stolen token bypasses authentication. Most tokens are bearer credentials: anyone who presents them is accepted.
Keep access tokens and sessions short-lived, and treat refresh tokens as the long-lived secrets they are.
Bind tokens to the client where you can: DPoP or mTLS for APIs, device-bound session credentials for browsers.
Make revocation work in practice: know which tokens exist, who holds them and how to kill them quickly.
Validate JWTs strictly and never trust the token to tell you how to validate it.

The tokens and sessions to protect

Artefact	What it does	Typical lifetime	Main risk
Session cookie	Keeps a user signed in to a web application or identity provider	Hours to weeks	Theft by infostealers or proxies; replay from another device
Access token	Authorises calls to an API	Minutes to an hour	Leakage in logs, URLs or memory; use against the wrong API
Refresh token	Gets new access tokens without user interaction	Days to months, sometimes unlimited	Long-term access if stolen, especially from SaaS integrations
ID token	Tells a client who signed in	Minutes	Misuse as an API credential
Personal access token and API token	Lets a person or script call an API directly	Often unlimited	Leaked in code; broad scopes; no owner
Federation assertion (SAML)	Carries sign-in from identity provider to application	Minutes	Forgery if the signing key is stolen

How tokens are stolen and abused

Infostealer malware copies cookies and tokens from browsers and developer tools, often on personal or unmanaged devices.
Adversary-in-the-middle phishing proxies the real sign-in and captures the session cookie issued after MFA. See the MFA Guide.
Appliance and application flaws leak sessions directly. CitrixBleed exposed session tokens that let attackers skip passwords and MFA.
Developer workstation compromise: in the Bybit hack, AWS session tokens from a developer's machine let attackers alter production code.
Third-party token stores: vendors that hold OAuth refresh tokens become a single point of failure, as in the Salesloft Drift and Klue breaches.
Leaks in code, logs and URLs: tokens committed to repositories, printed in logs or passed as query parameters. See the Home Depot token exposure.
Forged tokens: if a signing key is stolen, attackers can mint their own. The SolarWinds campaign forged SAML tokens, and the Coupang breach used a signing key that was never revoked. See the Cryptographic Key Management Guide.

Lifetimes

Keep access tokens short, typically minutes rather than hours, so a stolen one expires quickly.
Set session lifetimes by risk: shorter for administrators, sensitive applications and unmanaged devices; require re-authentication for sensitive actions.
Give refresh tokens an absolute maximum lifetime and an idle timeout, and use rotation, where each use issues a new refresh token and reuse of an old one revokes the chain.
Put an expiry on personal access tokens and API tokens, and scope them to the minimum.

Validation

Every API and application that accepts a token must check it. For JWTs, RFC 8725 sets out best practice:

Verify the signature with a key from the expected issuer, using a fixed allow-list of algorithms. Never accept none, and never let the token's header choose the algorithm or key location.
Check the issuer, audience, expiry and not-before claims.
Check scopes and claims against the action being requested.
Use opaque tokens with introspection where immediate revocation matters more than avoiding a network call.
Do not accept ID tokens as API credentials.

Binding tokens to the client

A bearer token works for anyone. A sender-constrained token only works for the client that holds a private key.

DPoP (RFC 9449): the client signs a proof with its own key for each request, and the token is bound to that key.
Mutual TLS binding (RFC 8705): the token is bound to the client's TLS certificate. Common for service-to-service and financial APIs.
Device Bound Session Credentials (DBSC): binds a browser session to a key held in the device's secure hardware, so a copied cookie is of little use elsewhere. Chrome made DBSC generally available on Windows in 2026, and support elsewhere is still developing.
Token protection features in identity providers can bind sign-in tokens to devices for supported applications.

Revocation and continuous evaluation

Know how to revoke every token type you issue, and test it. Many platforms cannot revoke self-contained JWTs before they expire, which is another reason to keep them short.
Revoke sessions and refresh tokens when a password is reset, an account is disabled, MFA is re-registered or risk rises.
Use continuous access evaluation and the OpenID Shared Signals Framework so applications react to these events in near real time.
For third-party integrations, keep a list of which vendors hold which tokens, so you can revoke them in one step during an incident. See the SaaS and OAuth App Governance Guide.
The Leaked Credential Response Playbook covers the incident steps.

Detecting token misuse

The same session or refresh token used from two devices, networks or countries.
Token use from infrastructure the user never signs in from, such as hosting providers or anonymising services.
Refresh token reuse after rotation.
Sudden bulk API export by an integration or user token.
Tokens used after the associated account was disabled.

The ITDR Guide covers identity detections more broadly.

Tokens for non-human identities and AI agents

Prefer federated, short-lived tokens over static API tokens for workloads. See the NHI Authentication Guide.
Give each AI agent task-scoped, short-lived tokens, and never forward a user's token to another service. See the AI Agent Authorisation Guide.
Keep tokens out of agent context and memory, where they can be exposed through prompt injection. See the AI Agent Memory Security Guide.

Practitioner checklist

Inventory the token types you issue and accept, and their lifetimes.
Shorten access token and high-risk session lifetimes; cap and rotate refresh tokens.
Validate JWTs strictly against a fixed algorithm list, issuer and audience.
Bind tokens with DPoP, mTLS or device-bound sessions where supported.
Make revocation work on password reset, disablement and risk events, and test it.
Keep tokens out of URLs, logs, code and AI agent context.
Track which third parties hold your users' tokens and how to revoke them.
Alert on token replay, reuse after rotation and bulk export.

Standards and references

Related NHI Mgmt Group resources: OAuth 2.0 and OpenID Connect Guide · Identity Provider and SSO Security Guide · MFA Guide · ITDR Guide

Token and Session Security Guide