Token theft is bypassing MFA and exposing SaaS trust chains

At a glance

What this is: This is an analysis of token theft across OAuth, session, and API tokens, with the core finding that bearer credentials let attackers bypass MFA and persist after login.

Why it matters: It matters because NHI and IAM teams must treat tokens as active access paths, not just authentication artefacts, or they will miss the real blast radius of SaaS compromise.

👉 Read Obsidian Security's analysis of token theft, OAuth, and session token abuse

Context

Token theft is a governance problem because authentication controls do not govern what happens after a token is issued. In SaaS and agentic environments, bearer credentials can outlive passwords, MFA prompts, and even user deactivation, which means the access model security teams think they have is not the access model attackers see. For IAM and NHI practitioners, the question is not whether logins are protected, but whether downstream token use is visible, bounded, and revocable.

The source article ties this to real-world SaaS compromise patterns where stolen tokens extend access across connected applications and vendor trust chains. That is typical of modern NHI risk: the sensitive identity is not a person at a login screen, but the non-human token that keeps working after the person is gone. The operational gap is persistent access without continuous verification.

Key questions

Q: How should security teams respond when they discover stolen OAuth or session tokens?

A: Containment should start with explicit token revocation, not just password resets. Security teams should disable the session, revoke refresh tokens and OAuth consents, and confirm that connected applications no longer accept the credential. They should also review API key exposure and monitor for follow-on use across SaaS integrations.

Q: Why do stolen tokens often survive password resets and MFA changes?

A: Because tokens are issued after authentication and often remain valid independently of later password or MFA updates. Unless the organisation revokes the token itself, the attacker can continue using the bearer credential until it expires or is explicitly invalidated. That is why token lifecycle control matters more than login hardening alone.

Q: What is the difference between token theft and traditional credential theft?

A: Traditional credential theft targets what a user knows, such as a password. Token theft targets what the system already trusts, such as an OAuth token, session cookie, or API key. That distinction matters because tokens often bypass MFA, work silently, and are harder to distinguish from legitimate automation traffic.

Q: How can organisations reduce the risk of token-based attacks in SaaS?

A: They should reduce token lifetime where possible, shrink scopes, rotate and revoke aggressively, and monitor token use for location, User-Agent, and volume anomalies. Just as important, they should map third-party integrations so one stolen token cannot silently extend into multiple connected systems.

Technical breakdown

Why bearer tokens bypass MFA and password controls

Bearer tokens are authorization artefacts, not fresh authentication events. Once an identity provider issues an OAuth access token, refresh token, session token, or API token, the receiving service accepts it as proof that authentication already happened. That is why MFA, password resets, and login anomaly checks do not reliably stop token misuse. In practice, the attacker does not need to defeat the login flow. They only need to capture a valid token and present it before expiry, or in the case of refresh tokens and many API keys, keep using it long after the original login is forgotten.

Practical implication: Treat token issuance and token revocation as separate control points in every IAM workflow.

OAuth refresh tokens versus short-lived access tokens

Short-lived access tokens limit exposure windows, but refresh tokens are the persistence layer. A refresh token can mint new access tokens repeatedly, which means incident response that only revokes current sessions leaves the attacker a path back in. This is especially dangerous in SaaS integrations because OAuth consent is often granted once and then forgotten, even when the connected app retains broad access. The real control problem is not just token lifetime, but whether the organisation can identify and revoke all authorisations tied to a compromised identity or vendor chain.

Practical implication: Build revocation playbooks that explicitly target refresh tokens and OAuth grants, not just active sessions.

API tokens, session hijacking, and the machine identity blast radius

API tokens and session cookies behave differently, but both create bearer-style access that can be abused at machine speed. Session hijacking inherits the user’s authenticated browser state, while API keys often provide long-lived programmatic access embedded in code, logs, or build systems. In NHI terms, these are identities with execution authority and often weak lifecycle governance. The blast radius grows when one token can reach multiple services through integration chains, because compromise is no longer limited to a single app. It becomes a trust graph problem, not a single credential problem.

Practical implication: Map integration chains and inventory all non-human credentials that can reach multiple downstream systems.

Threat narrative

Attacker objective: The objective is persistent, low-friction access to SaaS data and connected systems without triggering authentication alerts.

1. Entry occurs when an attacker captures OAuth, session, or API tokens through phishing proxies, malware, exposed logs, or vendor compromise.
2. Escalation happens when the stolen token is replayed against trusted SaaS or API endpoints, bypassing MFA and other login-time checks.
3. Impact follows when the attacker uses legitimate token-based access to move through connected applications and extract data at scale.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token theft is an identity governance failure, not just a phishing problem. The security industry often treats token theft as a detection issue, but the deeper issue is that bearer credentials create standing access after authentication. Once tokens are issued, the control plane shifts from login security to lifecycle governance, revocation, and behavioural validation. That makes token theft an NHI problem as much as an IAM problem. Practitioners should manage tokens as governed identities with explicit ownership and expiry.

Ephemeral access does not equal safe access. Short-lived tokens reduce exposure time, but they do not remove the trust assumptions embedded in OAuth, session, and API authentication flows. If an attacker can replay a valid credential before it expires, the organisation still loses. This is the ephemeral credential trust debt that many programmes are carrying: the shorter the lifetime, the more teams assume the risk has gone away. It has not. Practitioners need continuous monitoring, not just shorter TTLs.

Integration chains are now part of the attack surface. The article’s breach examples show that one compromised token can become a multi-tenant, multi-system access path through SaaS relationships. That means security teams must assess not only which applications hold tokens, but which downstream systems those tokens can reach. The governance model must extend beyond primary authentication into delegated access, third-party consents, and service-to-service trust. Practitioners should map every token to its reachable blast radius.

Behavioural detection is becoming the default control because static trust no longer scales. IP drift, ASN changes, and User-Agent anomalies are useful because they help distinguish valid tokens from valid use. That is an important distinction for NHI governance: the issue is not whether the token is authentic, but whether its use is expected. Organisations that cannot baseline normal token behaviour will continue to miss abuse. Practitioners should build detection around token usage patterns, not just identity events.

Revocation speed is now a resilience metric. Password resets alone are no longer a meaningful containment action when refresh tokens and OAuth grants remain live. The ability to revoke tokens quickly, trace the connected apps they authorise, and confirm that old grants are truly dead is a core incident response capability. In practice, token revocation maturity should be measured the same way access review maturity is measured. Practitioners should test it before they need it.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Forward pivot: For a broader view of how token abuse shows up in real incidents, see 52 NHI Breaches Analysis and the control gaps it exposes.

What this signals

Ephemeral credential trust debt: shortening token lifetimes helps, but it does not close the governance gap if revocation, inventory, and behavioural monitoring remain weak. The practical signal for IAM and NHI programmes is to treat token use as an ongoing authorisation problem, not a one-time authentication event.

With only 1.5 out of 10 organisations highly confident in securing NHIs, token-centric security is still immature in most environments. That confidence gap will matter more as SaaS trust chains and AI-driven automation increase the number of non-human credentials in circulation.

Security teams should expect more abuse of delegated access as identity becomes increasingly machine-mediated. The operational response is to combine access review, behavioural baselines, and integration mapping so that a valid token does not automatically equal a valid business transaction.

For practitioners

• Implement token-centric incident response Update playbooks so password reset, MFA reset, and user disablement are not treated as complete containment. Require explicit revocation of OAuth grants, refresh tokens, API keys, and browser sessions, then verify that access has actually stopped across connected systems.
• Inventory high-risk non-human credentials Build a live inventory of all OAuth, session, and API tokens with owners, scopes, expiry, and downstream reach. Prioritise credentials that can access production data, third-party SaaS, or multiple integrations, because those define the largest blast radius.
• Baseline normal token behaviour Monitor IP address, ASN, User-Agent, time of day, volume, and API pattern per token so misuse can be distinguished from legitimate automation. This is especially important where machine identities generate 24/7 access and high-volume requests.
• Reduce persistent delegated access Review long-lived refresh tokens and stale OAuth consents, then remove anything that no longer has a business owner or active use case. Pair that cleanup with tighter scope design so a stolen token cannot reach more systems than it needs to.

Key takeaways

• Token theft turns successful authentication into a long-lived access risk when bearer credentials are not tightly governed.
• The scale of the problem is visible in NHI research, where confidence in securing non-human identities remains materially lower than for human identities.
• The right response is token lifecycle governance, rapid revocation, and behavioural monitoring across every connected SaaS trust chain.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever presents it, without requiring the system to re-check the original login. In practice, this makes the token itself the security boundary, so theft of the token is functionally equivalent to theft of access.
• Refresh Token: A refresh token is a long-lived credential that can mint new access tokens after the original session expires. It is often the persistence mechanism in SaaS compromise because attackers can keep regenerating access even after passwords change unless the refresh token is revoked.
• Session Hijacking: Session hijacking is the takeover of an authenticated browser or application session by capturing its session token or cookie. The attacker does not need the password or MFA code because the token already represents a successful login and continues to be trusted by the application.
• Non-Human Identity: A non-human identity is any credentialed software entity, such as a token, key, certificate, service account, workload, bot, or AI agent. These identities often move data and trigger actions at machine speed, which makes lifecycle governance and behavioural monitoring critical.

Deepen your knowledge

Token theft, OAuth grants, and refresh token governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is still treating tokens as secondary artefacts, this is the right place to reset the model.

This post draws on content published by Obsidian Security: What is Token Theft? OAuth, Session & API Token Attacks Explained. Read the original.