Token theft is the new password theft: harden access now

Token theft has replaced password theft: why your old controls miss the real attack

A stolen password is often just the first step now. In 2026, attackers increasingly go after session tokens, OAuth refresh tokens, device cookies, and API bearer tokens because those artifacts let them skip the login flow entirely and act as a trusted user for hours or days. One compromised browser profile or CI runner can expose more access than a leaked password ever did.

That changes the defense model. If your controls stop at MFA prompts, password policy, and brute-force detection, you are protecting the wrong layer. The new question is not "Can someone guess the password?" but "Can someone copy, replay, or mint a token that your systems will accept?"

Why token theft beats password theft in 2026

Passwords are still stolen, but they are less useful to an attacker once MFA, passkeys, and conditional access are in place. Tokens are different: they are already authenticated, often already authorized, and frequently valid across multiple services.

The attacker’s math is better

A password spray might get a 1-3% success rate across a tenant. A stolen access token can yield immediate access with a 90-100% success rate until it expires or is revoked. If a refresh token is stolen from a developer laptop, the attacker may keep minting new access tokens for 24 hours, 7 days, or longer depending on your policy.

In real incident reviews, that means:

• A browser session cookie from a help desk workstation can lead to admin portal access in under 5 minutes.
• A stolen OAuth refresh token from a mobile device can survive password resets and MFA re-enrollment.
• A bearer token in a CI log can be replayed from anywhere unless it is sender-constrained.

The most common token theft paths

Attackers usually do not need a novel exploit. They use boring, reliable paths:

• Infostealers grabbing browser cookies and saved sessions.
• Phishing pages that proxy a real login and capture the session after MFA.
• Malicious browser extensions reading local storage or DOM content.
• Compromised endpoints exfiltrating tokens from memory, logs, or developer tooling.
• CI/CD secrets leaks in build logs, artifact metadata, or mis-scoped service accounts.

A 2026 enterprise red-team exercise often finds that the weakest link is not identity provider crypto; it is token handling in the client, proxy, or pipeline.

What token theft changes about your defence model

If tokens are the target, your defenses need to assume that authentication can be bypassed after the first successful login. That shifts security from "verify at login" to "continuously prove legitimacy during the session."

1) Bind tokens to the device or key

A bearer token is a photocopy of authority. Whoever holds it can use it. You want proof-of-possession or sender-constrained tokens wherever your stack supports them.

Use these patterns:

• mTLS-bound access tokens for service-to-service traffic.
• DPoP for browser or app flows where supported.
• Hardware-backed keys on endpoints for admin access.
• Short-lived session cookies tied to device posture and risk signals.

Example architecture decision:

• Human admin access: passkeys + device compliance + 15-minute session TTL.
• Internal APIs: mTLS + SPIFFE identities + 5-minute access tokens.
• Third-party integrations: scoped OAuth with refresh token rotation and anomaly detection.

A practical outcome: a stolen token becomes much harder to replay from an attacker VPS in another region.

2) Shrink token lifetime aggressively

Long-lived tokens are a liability. In 2026, a common enterprise target is:

• Access tokens: 5-15 minutes
• Admin session cookies: 10-20 minutes idle timeout, 30-60 minutes absolute timeout
• Refresh tokens: rotation on every use, with reuse detection and family revocation

If you shorten access token lifetime from 60 minutes to 10 minutes, you reduce the replay window by 83%. That does not stop theft, but it cuts the attacker’s useful time and increases the chance your telemetry catches them before they pivot.

A simple policy example:

{
  "access_token_ttl_seconds": 600,
  "refresh_token_rotation": true,
  "refresh_token_reuse_detection": true,
  "admin_session_absolute_timeout_minutes": 45,
  "idle_timeout_minutes": 15
}

3) Treat refresh tokens like crown jewels

Refresh tokens are more dangerous than access tokens because they can mint fresh access. If you store them in local storage, plain text config files, or long-lived browser state, you are giving attackers a durable foothold.

Use:

• Secure, HTTP-only cookies for browser sessions where possible.
• OS keychain or secure enclave storage for native apps.
• Vault-backed secret injection for automation.
• Rotation plus family invalidation on any reuse signal.

A useful benchmark: teams that moved from static refresh tokens to rotating refresh tokens with reuse detection typically cut successful session replay dwell time from days to under 30 minutes, because reuse becomes a high-signal event.

Build controls around token lifecycle, not just login

You cannot inspect a token after the fact and assume safety. You need controls across issuance, storage, transport, use, and revocation.

Issuance: make tokens narrow and contextual

Issue the smallest possible token for the shortest possible time. Include claims that let downstream systems enforce context:

• audience (aud)
• issuer (iss)
• tenant or org ID
• device or session ID
• risk level
• scopes, not broad roles

Example JWT claim set:

{
  "iss": "https://idp.example.com",
  "aud": "payments-api",
  "sub": "user-18422",
  "sid": "sess-7f9c2",
  "device_id": "dev-44a1",
  "acr": "phishing-resistant",
  "scope": "payments:read payments:refund",
  "exp": 1767225600
}

If your API accepts a token with the wrong audience or an overbroad scope, token theft becomes much more profitable.

Storage: stop putting tokens where malware can read them

The classic mistakes still show up in 2026:

• Access tokens in browser local storage.
• Refresh tokens in plaintext environment variables.
• CI secrets printed in logs for "debugging."
• Shared admin tokens in team chat.

Prefer secure storage and short retention. For web apps, HTTP-only cookies reduce exposure to XSS-driven token theft. For service accounts, use workload identity instead of static secrets whenever possible.

Transport and replay: assume interception is possible

Encrypt in transit, but do not stop there. TLS protects the wire; it does not stop a token copied from memory, logs, or a browser extension. Add replay resistance with sender constraints and nonce-based proof where your stack supports it.

A practical service-to-service pattern:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: payments
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payments-api
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  rules:
  - from:
    - source:
        principals: ["spiffe://corp/ns/checkout/sa/checkout"]
    to:
    - operation:
        methods: ["GET", "POST"]

This does not eliminate token theft, but it makes stolen credentials less reusable outside the expected workload identity.

Detection: what to log when passwords are no longer the signal

If tokens are the attack surface, your telemetry needs to focus on session behavior, not just login failures. Password-based alerts miss the compromise after the token is issued.

High-value signals to collect

Log and correlate:

• Token issuance time and client fingerprint
• Refresh token reuse events
• Geo-velocity and impossible travel
• Device posture changes mid-session
• New ASN or cloud-provider source for a previously corporate session
• Sudden privilege escalation inside an existing session
• API calls from a session that never completed normal interactive login

A mature detection stack can flag a token replay within 2-5 minutes if you correlate identity provider logs, CDN logs, and API gateway telemetry.

Example detection rule

selection:
  event_type: token_refresh
  reuse_detected: true
condition: selection
fields:
  - user_id
  - session_id
  - source_ip
  - user_agent
level: high

A reuse-detected refresh token should trigger family revocation, forced re-authentication, and endpoint triage. Do not wait for the user to report "weird behavior."

Benchmark your response time

For token theft, mean time to revoke matters more than mean time to detect. Good targets in 2026:

• Detect suspicious token reuse: under 5 minutes
• Revoke affected token family: under 2 minutes
• Disable high-risk sessions across the tenant: under 10 minutes
• Contain admin token compromise: under 15 minutes

If your revocation workflow depends on manual ticket approval, you are already behind.

Common Pitfalls

The same mistakes keep turning token theft into a major breach.

Assuming MFA solves session theft

MFA helps at login. It does not help after the attacker steals a valid session cookie. Use phishing-resistant MFA, but pair it with session binding and risk-based reauthentication.

Using bearer tokens for everything

Bearer tokens are easy to implement and easy to replay. Use them only where the blast radius is acceptable. For admin and service access, prefer sender-constrained or workload-bound approaches.

Keeping refresh tokens too long

A 30-day refresh token may look convenient, but it gives attackers a long-lived foothold. Rotate aggressively and revoke on reuse.

Logging secrets by accident

Debug logs, browser telemetry, and build output often capture tokens. Scrub headers, redact auth fields, and block secrets at the logging layer.

Overtrusting device compliance

A compliant device at 9:00 AM can become compromised at 9:07 AM. Re-check risk during the session, not only at login.

A practical 30-day hardening plan

You do not need a full identity redesign to make progress.

1. Inventory every token type you issue: access, refresh, API key, session cookie, service account secret.
2. Reduce access token TTL to 10-15 minutes for high-risk apps.
3. Turn on refresh token rotation and reuse detection everywhere supported.
4. Move browser sessions to HTTP-only cookies if you still store tokens in local storage.
5. Add sender constraints for internal APIs and admin flows.
6. Create alerts for token reuse, impossible travel, and session privilege escalation.
7. Test revocation speed with a tabletop or red-team scenario.

A realistic outcome for a mid-size enterprise: reducing token replay dwell time from 18 hours to under 1 hour, and from there to under 15 minutes for privileged sessions.

Key Takeaways

• Token theft is now the more common and more dangerous identity compromise path than password theft.
• Short-lived access tokens, rotating refresh tokens, and sender-constrained tokens reduce replay value dramatically.
• Protect storage first: HTTP-only cookies, secure enclaves, vault-backed secrets, and no plaintext tokens in logs or local storage.
• Detection must focus on session behavior, token reuse, and privilege escalation, not just failed logins.
• Measure revocation speed, not only detection speed; minutes matter more than policy wording.
• Start with a 30-day plan: inventory tokens, shorten lifetimes, enable rotation, and test incident response against session theft.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.