Learn IAM
Learn IAM
2026-02-27

Token Theft Is the New Password Spray: Hardening OAuth and SaaS Sessions with DPoP, CAEP, and Continuous Signals

Token replay has become one of the fastest paths to 'MFA bypass' in SaaS. This post lays out a practical token security stack: shorter lifetimes, DPoP/mTLS sender constraints, fast revocation, and CAEP-style continuous access evaluation—plus how to apply the same controls to non-human identities and AI agents.

Summary: Token replay (stolen session cookies, OAuth access tokens, and especially refresh tokens) has become one of the most reliable ways to bypass MFA and persist in SaaS. The fix isn’t one control—it’s a token security stack: shorter and better-scoped tokens, sender-constrained / proof-of-possession tokens like DPoP (and sometimes mTLS), fast revocation, and near-real-time response using Continuous Access Evaluation Profile (CAEP) style signals.

This post is enterprise-neutral and implementation-focused. It uses recent public reporting on identity-driven intrusions and token replay to ground the recommendations, then walks through what to change in your IdP, your resource servers, and your SaaS configuration.

Internal Learn IAM links used throughout (bookmark these):

Why this matters right now (and why MFA alone isn’t enough)

Identity defenders have been repeating the same warning for years: attackers don’t need to “hack” your systems if they can log in. What’s changed is how often attackers can skip the login step entirely.

A growing class of intrusions use valid tokens instead of passwords:

  • Session cookies stolen from a browser (often through adversary-in-the-middle phishing, info-stealers, or browser extension compromise)
  • OAuth access tokens and, worse, refresh tokens stolen from endpoints, CI/CD systems, SaaS integrations, or vendors in your supply chain
  • “Legitimate” OAuth flows abused in ways that turn user consent into a long-lived backdoor (e.g., malicious OAuth apps, device code phishing)

Recent public reporting underscores the trend:

  • Help Net Security, citing Unit 42’s Global Incident Response Report 2026, highlights identity weaknesses as a material factor in a large majority of investigations and calls out session hijacking and token theft as a way to bypass MFA and persist via long-lived tokens.
  • Obsidian Security describes token theft as a primary driver of modern SaaS compromise because bearer tokens can be replayed without re-authentication, and highlights how adversary-in-the-middle (AiTM) phishing captures tokens after MFA.
  • Okta’s analysis of the Salesloft/Drift incident describes token replay in an ecosystem context: attackers stole and replayed OAuth tokens used to connect Drift into systems like Salesforce and Google Workspace, and Okta highlights defenses such as inbound IP restrictions and DPoP support.

Put bluntly:

Password spraying and credential stuffing are still real, but token replay is now one of the shortest paths to “MFA bypass” at scale.

And AI accelerates it: faster reconnaissance, better social engineering, and more automation. Tokens are a perfect target because they convert one successful moment of access into sustained access.

Tokens are bearer credentials (treat them like stolen passwords)

Most enterprise stacks still implicitly treat tokens as if they are “safe to copy around”:

  • Access tokens live for an hour (sometimes much longer)
  • Refresh tokens live for days, weeks, or “until revoked”
  • OAuth grants to third-party apps persist until someone reviews them (often never)
  • Sessions aren’t continuously re-evaluated when risk changes

The core issue is simple:

  • Bearer tokens are possession-based. Whoever has them can use them.
  • Therefore a stolen token is functionally equivalent to a stolen password + a completed MFA challenge.

The common failure mode

A lot of “MFA bypass” stories are really this:

  1. User completes MFA successfully.
  2. The IdP issues a session cookie / access token.
  3. Attacker steals the token.
  4. Attacker replays the token somewhere else.
  5. The system says, “looks good; MFA already happened.”

When you design token security, assume your attacker is excellent at step 3.

Three token-theft scenarios you should design for

1) Adversary-in-the-middle (AiTM) phishing steals post-MFA sessions

Modern phishing kits proxy the real login page. The victim completes MFA against the real IdP, but the attacker captures the resulting session cookie/token.

What breaks: classic MFA, user awareness training, and controls that only trigger at the login event.

What helps: sender-constrained tokens, device binding, strong session management, and continuous access evaluation.

2) SaaS integration / vendor compromise turns OAuth tokens into a supply-chain blast radius

In OAuth integrations, tokens often represent “always on” access between SaaS systems. In the Salesloft/Drift scenario described publicly, stolen OAuth tokens were replayed to access connected environments.

What breaks: “It’s just an integration token.” (Integration tokens are often high-privilege and long-lived.)

What helps: least-privilege scopes, short lifetimes, rotation, IP/network constraints, token exchange patterns, and fast revocation.

3) OAuth device code phishing abuses legitimate login UX

Attackers send the victim to a legitimate device login URL and trick them into entering an attacker-controlled code. The user authenticates “normally” and approves the device.

What breaks: URL inspection and normal “don’t click weird links” training—because the domain can be legitimate.

What helps: policy restrictions on device code flow, very explicit user guardrails, and detection of abnormal device registrations.

Where CAEP / continuous access evaluation fits (closing the time gap)

If token replay is fast, your response needs to be fast.

The core CAEP model is:

  • Something changes (risk spike, device posture changes, token suspected stolen, user disabled, session revoked)
  • A system emits a security event signal
  • Relying parties (apps / APIs / SaaS) receive the signal and immediately re-check access or kill the session

CAEP isn’t magic by itself; it’s the connective tissue that makes “continuous enforcement” real across many apps.

If you want the conceptual anchor, start here:

Even if you don’t implement CAEP end-to-end today, you can apply the same philosophy internally:

  • centralize risk decisions
  • propagate revocation quickly
  • force re-auth when conditions change

Practical takeaway: stop thinking of access as “a login event + a token lifetime.” Start thinking of access as “a session that remains valid only while conditions remain true.”

A practical token security stack

You get the best outcomes by layering controls. The goal is to make tokens:

  1. harder to steal,
  2. harder to replay,
  3. easier to revoke,
  4. continuously evaluated.

Layer 0: Inventory and classify tokens (you can’t protect what you don’t see)

Before you tune lifetimes or add proof-of-possession, you need an inventory.

What to inventory:

  • IdP-issued browser sessions (SSO cookies)
  • OAuth access + refresh tokens for first-party apps
  • OAuth grants to third-party apps (including user-consented apps)
  • service-to-service tokens (CI/CD, automation, “agent” tokens)
  • legacy API keys still lurking in places they shouldn’t

Where to look:

  • IdPs (Okta, Microsoft Entra ID, Ping, ForgeRock, Keycloak)
  • SaaS admin consoles (Salesforce, Google Workspace, GitHub)
  • cloud platforms (AWS IAM, Azure, GCP)
  • CI/CD (GitHub Actions, GitLab CI, CircleCI, Jenkins)
  • secrets managers (HashiCorp Vault, AWS Secrets Manager)

Output you want: a spreadsheet (or CMDB entry) per token type with:

  • owner (human + team)
  • issuer (IdP / SaaS)
  • audience/resource
  • scopes/permissions
  • lifetime + rotation policy
  • revocation path (exact buttons/API calls)
  • monitoring signals available

Layer 1: Set sane default lifetimes (and be explicit about exceptions)

Long-lived tokens make incident response miserable.

A useful baseline that works in many enterprises:

  • Access tokens: 5–15 minutes for high-risk APIs; 15–60 minutes for typical APIs
  • Refresh tokens: rotate on every use where possible; set absolute lifetimes (days/weeks, not months)
  • Browser sessions: idle timeout + absolute timeout; step-up for sensitive actions
Token / credential typeTypical useWhy attackers like itRecommended lifetime guidanceBest controls to add
Session cookieBrowser SSO sessionSteals “already MFA’d” sessionIdle timeout (e.g., 15–60m) + absolute timeout (e.g., 8–24h)phishing-resistant MFA, device binding, continuous evaluation, anomaly detection
OAuth access token (bearer)API callsEasy replay if stolen5–60 minutes depending on risknarrow scopes, audience restriction, DPoP or mTLS, rate limiting
OAuth refresh tokenToken renewalPersistence even after password resetRotate-on-use + absolute lifetime (days/weeks)refresh token rotation, sender constraints, revoke on risk
OAuth device codeDevice loginUser can be tricked into approvingN/A (flow-specific)restrict flow, user education, conditional access policies
API key (static)Legacy automationNever expiresAvoid; migratereplace with workload identity / short-lived tokens

This table is intentionally conservative. Your exact numbers depend on UX constraints and app architecture, but “hours to days” for bearer tokens is increasingly hard to justify.

Layer 2: Move from bearer tokens to sender-constrained tokens (DPoP and/or mTLS)

If you only do one “new” token-hardening initiative this year, do this.

What DPoP does

DPoP (Demonstrating Proof of Possession) binds a token to a client-held key. If an attacker steals the token but doesn’t have the private key, replay fails.

DPoP is especially attractive because it can work in architectures where full end-to-end mTLS is unrealistic.

What it looks like on the wire (concrete example)

DPoP adds a signed proof JWT (the DPoP header) to the request. The proof binds:

  • the HTTP method (htm)
  • the URL (htu)
  • a timestamp/nonce (to reduce replay)
  • the public key (via JWK thumbprint)

Example (simplified):

http
GET /v1/payroll/export HTTP/1.1
Host: api.example.com
Authorization: DPoP eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9....
DPoP: eyJhbGciOiJSUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7...}}....

On the resource server side, you validate:

  1. the access token (signature, issuer, audience, expiry)
  2. the DPoP proof JWT (signature + correct htm/htu + freshness)
  3. that the token is bound to the DPoP key (the cnf.jkt claim in the access token matches the proof key)

If any of those fail, reject the request.

Resource server checklist for DPoP

  • Enforce aud strictly (don’t accept “any audience” tokens)
  • Validate cnf.jkt in the token for DPoP-bound tokens
  • Enforce nonce/freshness windows
  • Store recent DPoP jti values briefly to prevent replay at the HTTP layer
  • Log DPoP failures separately (they’re high-signal)

Where mTLS still shines

mTLS-bound tokens can be excellent for:

  • service-to-service in controlled environments
  • high assurance integrations where client certificates are manageable

The tradeoff is operational cost: certificate issuance, rotation, revocation, and client library support.

Comparison table: replay-mitigation options

OptionStops token replay?Where it fits bestOperational complexityNotes
Shorter token lifetimesReduces windowEverywhereLowDoesn’t stop replay; just limits blast radius
IP allowlisting / inbound IP restrictionsSometimesSaaS admin APIs, critical SaaS appsMediumStrong when supported; brittle for roaming users
DPoP (PoP tokens)YesFirst-party apps, mobile, modern SPAs, APIsMediumRequires client key management + server support
mTLS-bound tokensYesWorkloads, backend servicesHighCertificate lifecycle is the hard part
Device binding / attestationPartialManaged endpointsMedium/HighDepends on platform and IdP support

Okta’s public incident analysis emphasizes inbound IP restrictions and DPoP as meaningful controls. That combination is a good blueprint: use network constraints where you can, and use proof-of-posession where you can’t.

Layer 3: Revocation that actually works (and is fast)

Revocation is where a lot of token strategies die.

You need three things:

  1. A reliable kill switch (disable user, revoke session, revoke refresh tokens, revoke OAuth grants)
  2. Fast propagation to apps (push signals; don’t wait for long token expiry)
  3. Clear ownership (who can revoke what, and under what conditions)

Build a “token emergency brake” runbook

At minimum, for your top 10 SaaS apps and your top 10 internal APIs, document:

  • how to revoke user sessions
  • how to revoke refresh tokens
  • how to revoke OAuth grants / connected apps
  • how to rotate integration credentials
  • what logs to pull (and from where)
  • what “containment success” looks like

Make it a checklist your incident commander can execute at 2 AM.

For your own APIs: don’t depend on JWT expiry alone

JWTs are great for stateless validation, but “stateless” is a liability during an incident.

Common enterprise patterns:

  • include a sid (session id) in tokens and maintain a server-side revocation list
  • include a user token_version or session_version claim that can be incremented to invalidate prior tokens
  • cache revocation decisions at the edge for performance

Layer 4: Continuous access evaluation (risk changes should terminate sessions)

If you have adaptive authentication / conditional access (Okta, Entra ID, PingOne, etc.), don’t limit it to the login moment.

Trigger session termination or step-up when:

  • impossible travel
  • token used from new ASNs/geos
  • device posture drops (EDR alert, device becomes unmanaged)
  • sensitive data export spikes
  • OAuth grant created outside normal patterns

This is the philosophical goal of CAEP: consistent, near-real-time enforcement across many apps.

Layer 5: Non-human identity (NHI) and AI agent tokens (treat them as production-critical)

AI agents and automation expand the token surface area dramatically:

  • agents call APIs
  • agents impersonate users (delegation)
  • agents run in CI/CD
  • agents act across SaaS boundaries

If you protect humans but not workloads, attackers will pivot to workloads.

Learn IAM topics:

Concrete guidance:

  • Prefer short-lived, audience-restricted tokens minted just-in-time.
  • Use cloud-native workload identity where possible:
    • AWS IAM roles (STS)
    • Azure Managed Identities
    • GCP Workload Identity
  • In Kubernetes, use service accounts + projected tokens; consider SPIFFE/SPIRE where appropriate.
  • Avoid long-lived API keys in CI systems; use OIDC federation from CI to cloud (GitHub Actions OIDC to AWS/Azure/GCP).

Agent-specific advice: avoid giving an agent a broad “human-like” token. Instead:

  • give the agent a narrow, task-specific token
  • constrain by audience, scope, and time
  • require step-up / human approval for privilege escalation
  • log agent actions separately (agent identity is not a user identity)

Implementation playbook (phased adoption)

You can’t flip every switch in a week. This sequence is meant to be realistic.

Phase 1 (0–30 days): Reduce obvious exposure

  1. Shorten access token lifetimes for high-risk APIs.
  2. Enable refresh token rotation where supported.
  3. Audit OAuth grants (user-consented apps, third-party integrations) and remove stale grants.
  4. Turn on inbound IP restrictions for critical SaaS admin surfaces where supported.
  5. Create incident runbooks for: revoke sessions, revoke refresh tokens, revoke OAuth grants.

Deliverable: a documented “token emergency brake” runbook and materially reduced persistence.

Phase 2 (30–90 days): Add sender constraints and strong session controls

  1. Implement DPoP for one high-value API + one high-value client (mobile app or internal SPA).
  2. Add audience restrictions and strict scope design to tokens.
  3. Implement proof validation at the resource server (reject replay).
  4. Add step-up authentication for sensitive operations (export data, admin actions).

Deliverable: token replay becomes significantly harder in the highest-value path.

Phase 3 (90–180 days): Continuous access evaluation + ecosystem hardening

  1. Expand continuous risk evaluation beyond login (terminate sessions on risk spikes).
  2. Integrate CAEP-like signals where available; otherwise implement event-driven session revocation internally.
  3. Harden SaaS integrations:
    • minimize scopes
    • enforce IP allowlists
    • rotate integration secrets/tokens
    • require vendor security baselines (IPSIE-style)
  4. Apply the same controls to non-human identities and agents.

Deliverable: faster containment and fewer “token replay = full compromise” outcomes.

What to measure (so you know it’s working)

Token programs fail when they’re purely policy documents. Measure outcomes:

Closing: treat token security as an IAM core competency

The industry is converging on a clear direction:

  • short-lived tokens
  • proof-of-possession (DPoP, mTLS)
  • rapid revocation
  • continuous evaluation (CAEP-style)
  • ecosystem standards/baselines (e.g., IPSIE)

If your security posture assumes “MFA protects us,” token replay will keep proving you wrong. If your posture assumes “tokens will get stolen” and designs around replay, revocation, and continuous evaluation, you’ll cut off one of the most reliable attack paths in modern SaaS.

References (selected)

  • Help Net Security (Feb 2026): One stolen credential is all it takes to compromise everything (Unit 42 IR report highlights identity, session hijacking, token theft)
  • Obsidian Security (Feb 2026): Token-Based Attacks: How Attackers Bypass MFA
  • Okta Newsroom: The Salesloft incident: A wake-up call for SaaS security and IPSIE adoption