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, revocation and detection controls that limit the damage. It is written for identity architects, API owners and detection engineers, and draws on IETF best current practice and NIST IR 8587, which NIST and CISA finalised in September 2026.
Key takeaways
- A stolen token bypasses authentication. Most tokens are bearer credentials: anyone who presents them is accepted, so a token that has passed MFA is as good as the user's password and second factor together.
- Short lifetimes are the baseline. NIST IR 8587 recommends access and identity tokens be valid for no more than one hour, and refresh tokens for people should not outlive the reauthentication time frames in SP 800-63B-4.
- Bind tokens to the client where you can: DPoP or mutual TLS for APIs, device-bound session credentials and identity provider token protection for browsers and devices.
- Revocation must work in practice: know which tokens exist, who holds them and how to kill them, and push revocation to relying parties with shared signals rather than waiting for expiry.
- Validate strictly and never trust the token to tell you how to validate it: fixed algorithms, expected issuer and audience, explicit typing and keys that are scoped and protected.
The tokens and sessions to protect
Start with an inventory of every token type your organisation issues and every type it accepts. NIST IR 8587 says agencies and cloud providers must document each type of token they use, and that assertions and tokens must carry at least an issuer, a subject, an audience and a validity period. The table below covers the common artefacts.
| 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 |
| Workload token (cloud session credentials, Kubernetes service account token, SPIFFE JWT-SVID) | Authenticates a service, pipeline or AI agent | Minutes to hours when federated; unlimited when static | Theft from metadata endpoints, containers and CI logs |
Record for each type its issuer, consumers, lifetime, revocation method, binding and where copies sit. The gaps are usually where incidents start.
How tokens are stolen and abused
MITRE ATT&CK tracks theft as T1539 (Steal Web Session Cookie) and T1528 (Steal Application Access Token), and reuse as T1550.001 (Application Access Token), noting that direct API access through a token "negates the effectiveness of a second authentication factor".
- Infostealer malware copies cookies and tokens from browser stores and developer tools, often on personal or unmanaged devices. See the Infostealer Threat Guide.
- Adversary-in-the-middle phishing proxies the real sign-in and captures the session cookie issued after MFA. See the AiTM Phishing Guide.
- Appliance and application flaws leak sessions directly. In CitrixBleed 2023, a memory leak returned valid NetScaler session cookies that skipped passwords and MFA, and CitrixBleed 2 (CVE-2025-5777) repeated the pattern in 2025. Patching did not end sessions already stolen.
- Support and troubleshooting files: in the Okta Support System Breach 2023, HAR files uploaded to support cases held session tokens, and Okta said five customers' sessions were hijacked.
- Developer workstation compromise: in the Bybit Hack 2025, Safe says attackers hijacked a developer's AWS session tokens to get around MFA and alter code served to signers.
- Third-party token stores: vendors that hold OAuth refresh tokens become a single point of failure, as in the Salesloft Drift Breach 2025 and the Klue OAuth Breach 2026.
- Leaks in code, logs and URLs: tokens committed to repositories, printed in logs or passed as query parameters. The Home Depot Token Exposure 2025 involved a GitHub token that TechCrunch says stayed exposed from early 2024.
- Forged tokens: if a signing key is stolen, attackers mint their own. The SolarWinds Supply Chain Compromise forged SAML tokens, the Microsoft Storm-0558 Key Breach 2023 used a consumer signing key that should have been retired, and the Coupang Breach 2025 used a key that was never revoked after its holder left. See the Cryptographic Key Management Guide.
Lifetimes
Lifetime is the cheapest control: it caps how long a stolen token is useful. Treat these figures as starting points to tailor by risk.
| Token or session | Baseline | Source |
|---|---|---|
| Access and identity tokens | No more than one hour; expired tokens must be rejected | NIST IR 8587, section 5.3.1.1 |
| Refresh tokens for people in interactive sessions | Should not exceed reauthentication time frames: 24 hours overall and 1 hour inactivity at AAL2; 12 hours overall and 15 minutes inactivity at AAL3 | NIST IR 8587 with SP 800-63B-4 |
| Refresh tokens for APIs, workloads and other non-human use | As short as possible, with compromise detection, device registration and, where possible, proof of possession | NIST IR 8587 |
| Web application idle timeout | 2 to 5 minutes for high-value applications, 15 to 30 minutes for low-risk ones, plus an absolute timeout | OWASP Session Management Cheat Sheet |
| Token and assertion signing keys | No more than 90 days of active use for high-impact systems; under one year for moderate and low impact | NIST IR 8587, section 5.1.1 |
- Set session lifetimes by risk, shorter for administrators and unmanaged devices, and re-authenticate for sensitive actions.
- Give refresh tokens an absolute maximum lifetime and an idle timeout. RFC 9700 says refresh tokens should expire after a period of client inactivity, and that public clients must use sender-constrained refresh tokens or rotation, where each use issues a new token and reuse of an old one revokes the active token.
- Put an expiry on personal access tokens and API tokens, and scope them to the minimum. Tokens with no expiry are what the OWASP Non-Human Identities Top 10 calls long-lived secrets (NHI7).
- Understand vendor exceptions: Microsoft documents token lifetimes of up to 28 hours in continuous access evaluation sessions, where critical events drive revocation. That is only safe if the event channel works.
Validation
Every API that accepts a token must check it on every request. RFC 8725 sets out JWT best practice, and RFC 9068 adds rules for JWT access tokens:
- Algorithms: verify the signature against a fixed allow-list of algorithms. Never accept
nonewhere a signature is expected, and never let the header choose the algorithm. RFC 8725 says libraries must let the caller specify supported algorithms and must not use any others. - Keys: fetch verification keys only from the expected issuer's metadata; do not follow
jkuorx5uURLs without an allow-list, and sanitisekid. HMAC keys must never be passwords. - Claims: check issuer, audience, expiry and not-before. RFC 8725 says a relying party must reject a JWT whose audience is missing or not its own; NIST IR 8587 adds that a missing or wrong audience should raise a security alert.
- Type: use explicit typing so one kind of JWT cannot be substituted for another. RFC 9068 requires resource servers to check that the
typheader isat+jwt, which RFC 9068 says helps resource servers tell JWT access tokens apart from OpenID Connect ID tokens. - Scope: check scopes and claims against the action requested. RFC 9700 says access tokens should be restricted to the minimum privileges, resources and actions needed.
- Key scope: confirm the signing key is valid for this tenant and environment. Storm-0558 succeeded partly because mail systems accepted consumer-signed tokens for enterprise accounts.
- Opaque tokens: use introspection (RFC 7662) where immediate revocation matters most.
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. RFC 9700 says authorisation and resource servers should use sender-constraining mechanisms such as mutual TLS or DPoP to prevent misuse of stolen and leaked access tokens.
| Mechanism | How it binds | Best fit | Limits |
|---|---|---|---|
| DPoP (RFC 9449) | Client signs a proof per request with its own key; the proof covers method, URI and a hash of the access token | Public clients, single-page and mobile apps, APIs | Malicious script in the client can still create proofs; server nonces narrow the window |
| Mutual TLS (RFC 8705) | Token is bound to the client's TLS certificate | Service to service, financial and regulated APIs | Needs certificate issuance and TLS termination that passes the client certificate through |
| Device Bound Session Credentials | Chrome keeps a private key in secure hardware such as a TPM and proves possession before short-lived cookies are refreshed | Browser sessions to web applications | Falls back to normal cookies on unsupported hardware; the site must add registration and refresh endpoints |
| Identity provider token protection | Sign-in session tokens are bound to a registered device | Workforce sign-in to supported apps | Supported apps, platforms and browsers vary by vendor |
| Workload identity (for example SPIFFE SVIDs) | Short-lived, automatically rotated credentials bound to a specific workload | Services, pipelines and agents | Requires a trusted control plane for issuance |
Device Bound Session Credentials became generally available in Chrome for Windows in May 2026; Google says it is on by default for Google Workspace customers. Microsoft Entra Token Protection is generally available for native applications such as Exchange Online, SharePoint Online and Teams on Windows, with browser support in preview. Start with administrator sessions, integration refresh tokens and workload tokens with write access.
Revocation and continuous evaluation
NIST IR 8587 is candid: immediate global revocation is not always possible for stateless tokens before they expire, which is why short access tokens paired with refresh tokens or reauthentication matter. It says identity providers must not accept refresh tokens tied to a suspect identity token without reauthenticating the user.
- Know how to revoke every token type you issue, and test it. RFC 7009 requires revocation of refresh tokens and recommends it for access tokens.
- Revoke on events: sessions and refresh tokens should end when a password is reset, an account is disabled, MFA is re-registered or risk rises. RFC 9700 lists password change and logout as events that can trigger automatic refresh token revocation.
- Propagate revocation: the OpenID Shared Signals Framework and its Continuous Access Evaluation Profile (CAEP) carry events such as Session Revoked, Token Claims Change and Credential Change between identity providers and applications. NIST IR 8587 says providers and agencies should implement session revocation signals.
- Know who holds your tokens, so vendor grants can be revoked in one step. See the SaaS and OAuth App Governance Guide.
The Leaked Credential Response Playbook covers the incident steps.
Detecting token misuse
NIST IR 8587 suggests logging token type, issuer, scopes, client or user, audience and timestamped issuance, refresh, acceptance, rejection and revocation events, and says tokens themselves must never be logged.
| Signal | Data source | ATT&CK |
|---|---|---|
| Same session or refresh token used from two devices, networks or countries | Identity provider sign-in logs, application session logs | T1539, T1550.001 |
| Token use with no preceding interactive sign-in or MFA | Non-interactive sign-in logs, SaaS audit logs | T1550.001 |
| Token use from hosting providers or anonymising services the user never signs in from | Sign-in logs enriched with network reputation | T1550.001 |
| Refresh token reuse after rotation | Authorisation server logs | T1528 |
| Access to browser cookie stores or browser process memory by unusual processes | EDR file and process telemetry | T1539 |
| Token retrieval from instance metadata or container service account paths followed by API calls from elsewhere | Cloud audit logs, Kubernetes audit logs | T1528 |
| Sudden bulk export by an integration or user token | SaaS audit and API logs | T1550.001 |
| Tokens rejected for wrong audience, bad signature or unknown key | API gateway and resource server logs | Possible forgery attempt |
Send token events to the SIEM in a consistent schema, and correlate identity provider, SaaS and endpoint data. The ITDR Guide covers identity detections more broadly.
Tokens for non-human identities and AI agents
NIST IR 8587 says workload identities must use tightly scoped, short-lived tokens issued through approved enterprise identity platforms, and should use sender-constrained mechanisms such as mTLS or DPoP whenever feasible. It also says tokens must be kept out of logs, CI/CD pipelines and build artefacts, and that pipelines must retrieve secrets only through secret management systems.
- Federate workloads: prefer federated, short-lived tokens over static API tokens. See the Workload Identity Federation Guide and the NHI Authentication Guide.
- Task-scoped agent tokens: give each AI agent short-lived tokens scoped to the task, and do not forward a user's token to another service; exchange it for a narrower one. See the AI Agent Authorisation Guide and the OAuth Token Exchange and Delegation Guide.
- Keep tokens out of agent context: tokens in prompts, tool output or memory can be exposed through prompt injection. See the AI Agent Memory Security Guide.
- Treat agent sessions as high value: in the Meta Muse Agent Hijack 2026, a researcher's proof of concept listed theft of the agent's authentication material among the impacts of a local setting that redirected its traffic.
- Govern consent: an OAuth grant to an agent is a new identity acting as the user. NIST IR 8587 says it is not a comprehensive guide to AI agent access risks.
Framework mapping
Control IDs below were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 (release 5.2.0) catalogue, the ISO/IEC 27001:2022 Annex A control list, the CIS Controls v8.1 list and the OWASP NHI Top 10 2025. This is an NHI Mgmt Group alignment, not an official crosswalk. IA-13 was added in SP 800-53 release 5.1.1 in response to high-profile token incidents, according to NIST IR 8587.
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 |
|---|---|---|---|---|---|
| Token issuance and management | PR.AA-04 | IA-13, IA-13(3) | A.5.17, A.8.5 | 6 | NHI4 |
| Token and assertion validation | PR.AA-04 | IA-13(2) | A.8.5 | 16 | NHI4 |
| Lifetimes, timeouts, reauthentication | PR.AA-03 | AC-12, IA-11 | A.8.5 | 6 | NHI7 |
| Session authenticity and binding | PR.AA-04, PR.DS-02 | SC-23, SC-23(1), SC-23(3), SC-8 | A.8.5 | 16 | NHI4 |
| Signing key protection | PR.DS-01 | IA-13(1), SC-12 | A.8.24 | 3 | NHI2 |
| Keeping tokens out of code, logs and pipelines | PR.DS-01, PR.PS-06 | IA-5(6), IA-5(7) | A.5.17, A.8.28 | 3, 16 | NHI2 |
| Revocation on account and risk events | PR.AA-01, RS.MI-01 | AC-2(3), IA-13(3), IR-4 | A.5.18, A.5.26 | 5, 6, 17 | NHI1 |
| Third parties holding tokens | GV.SC-07, DE.CM-06 | SA-9 | A.5.19, A.5.23 | 15 | NHI3 |
| Detection of token misuse | DE.CM-03, DE.AE-03 | AU-2, AU-6, SI-4 | A.8.15, A.8.16 | 8 | No direct item |
Common failure patterns
- Patching without killing sessions: the vulnerable appliance is fixed, but cookies stolen before the patch keep working. Both CitrixBleed incidents required every existing session to be terminated.
- Tokens in troubleshooting artefacts: HAR files and support bundles carry live session tokens to weaker systems, as the Okta support breach showed.
- Signing keys that never rotate: a key that outlives its owner or its intended retirement date lets anyone holding it mint tokens. Storm-0558 and Coupang both involved keys that should no longer have been valid.
- Validation left to the library defaults: applications assume the library checks issuer, audience and key scope. Microsoft says this assumption contributed to Storm-0558.
- Refresh tokens with no ceiling: one vendor breach exposes every customer, as in Salesloft Drift and Klue.
- Untested revocation: the runbook says "revoke all sessions", but nobody knows whether downstream applications honour it.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Token types inventoried with owner, lifetime and revocation method | Coverage of the attack surface | Up, to 100% |
| Median and maximum access token lifetime by application | Window a stolen token is useful | Down, to one hour or less |
| Refresh tokens and personal access tokens with no expiry | Long-lived exposure | Down, to zero |
| Share of high-value APIs and admin sessions using sender-constrained or device-bound tokens | Protection against replay | Up |
| Time from account disablement or password reset to last accepted token | Whether revocation really works | Down, to minutes |
| Applications receiving shared signals or continuous access evaluation events | Reach of revocation | Up |
| Token replay and reuse-after-rotation alerts triaged within target | Detection effectiveness | Up |
| Tokens found in logs, code, tickets or support files per month | Hygiene and secret scanning | Down |
Implementation roadmap
| Phase | Actions | Outcome |
|---|---|---|
| First 30 days | Inventory token types issued and accepted; list third parties holding refresh tokens; confirm revocation steps for each type; add token issuance, refresh and rejection events to the SIEM; scan logs, tickets and repositories for tokens | You know what exists and can revoke it |
| Days 31 to 90 | Cut access token lifetimes to one hour or less; cap and rotate refresh tokens; expire personal access tokens; enforce strict JWT validation with fixed algorithms, audience and explicit typing; deploy replay and reuse-after-rotation detections | Stolen tokens expire fast and misuse is visible |
| Days 91 to 180 | Roll out sender-constrained tokens (DPoP or mTLS) for high-value APIs; enable device-bound sessions and identity provider token protection for admins; connect applications to shared signals or continuous access evaluation; move workloads and AI agents to federated, task-scoped tokens; rehearse a mass revocation | Stolen tokens stop working elsewhere and revocation is proven |
Practitioner checklist
- Inventory the token types you issue and accept, with lifetimes, owners and revocation methods.
- Keep access and identity tokens to one hour or less; cap, rotate and idle-expire refresh tokens.
- Validate JWTs against a fixed algorithm list, expected issuer, audience, type and key scope.
- Protect and rotate token signing keys on a documented schedule.
- Bind tokens with DPoP, mTLS or device-bound sessions where supported, starting with admins and integrations.
- Revoke sessions and refresh tokens on password reset, disablement, MFA change and risk events, and test it.
- Terminate all sessions after any compromise of an appliance or identity provider that issued them.
- Keep tokens out of URLs, logs, code, support files and AI agent context.
- Track which third parties hold your users' tokens and how to revoke them in one step.
- Alert on token replay, reuse after rotation, non-interactive use without sign-in and bulk export.
Standards and references
- NIST: IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse
- IETF: RFC 9700, Best Current Practice for OAuth 2.0 Security
- IETF: RFC 8725, JSON Web Token Best Current Practices
- IETF: RFC 9068, JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
- IETF: RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- IETF: RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
- IETF: RFC 7009, OAuth 2.0 Token Revocation
- NIST: SP 800-63B-4, Authentication and Authenticator Management
- OpenID Foundation: Shared Signals Working Group
- OWASP: Session Management Cheat Sheet
- Chrome for Developers: Device Bound Session Credentials (DBSC)
- MITRE ATT&CK: T1539 Steal Web Session Cookie
Related NHI Mgmt Group resources: OAuth 2.0 and OpenID Connect Guide · Identity Provider and SSO Security Guide · MFA Guide · ITDR Guide