Token theft bypasses MFA by turning bearer tokens into access

At a glance

What this is: This is an analysis of how stolen authentication tokens let attackers bypass MFA and keep accessing SaaS, APIs, and cloud resources.

Why it matters: IAM and NHI practitioners need to treat tokens as bearer credentials with their own lifecycle, because MFA at login does not stop replay, persistence, or SaaS-to-SaaS abuse.

By the numbers:

• Token theft accounted for 31% of Microsoft 365 breaches in 2025, making it the primary attack vector surpassing traditional credential compromise.
• AiTM phishing attacks increased 146% over the past year, with nearly 40,000 token theft incidents detected daily across Microsoft environments.
• The Salesloft-Drift incident extended attacker access into over 700 customer environments through stolen OAuth tokens.

👉 Read Obsidian Security's analysis of token theft, MFA bypass, and SaaS replay

Context

Token theft is an IAM failure mode, not just a phishing problem. Once an authentication token is issued, it becomes a bearer credential that can be replayed without passwords or MFA, which means the real control plane shifts from login events to token use, scope, and revocation.

For NHI governance, this matters because service tokens, OAuth grants, refresh tokens, and session cookies now sit on the same risk continuum as service accounts and API keys. The article’s starting point is typical for modern SaaS environments, where authentication has been fragmented across applications but token visibility has not kept pace.

Key questions

Q: How should security teams detect token theft if MFA was already completed?

A: Focus on how the token is used, not how the user logged in. Look for unusual IP addresses, new geolocations, User-Agent changes, impossible travel, bulk data access, and access to applications or scopes the account rarely uses. Successful logins are not enough to prove legitimacy once a bearer token is stolen.

Q: When does token theft create more risk than password theft?

A: Token theft becomes more dangerous when the stolen credential is already authorized, long-lived, or linked to delegated SaaS integrations. In those cases, the attacker skips reauthentication, survives password resets, and can move through trusted app connections. That is why token lifecycle and scope matter as much as login hygiene.

Q: What is the difference between MFA bypass and token replay?

A: MFA bypass attacks target the authentication step itself, usually by intercepting or defeating the second factor. Token replay happens after authentication, when an attacker steals a valid session or OAuth token and reuses it as a bearer credential. The defense model is different: MFA hardening reduces capture, but replay prevention depends on binding, monitoring, and revocation.

Q: How should organisations reduce the blast radius of stolen OAuth tokens?

A: Limit delegated scopes, review third-party integrations regularly, shorten token lifetimes, and revoke refresh tokens when the business need ends. Organisations should also separate privileged workflows from everyday SaaS access so a stolen token cannot automatically reach high-value systems or downstream customer environments.

Technical breakdown

Why bearer tokens bypass MFA

OAuth access tokens and session cookies are bearer credentials, which means the system trusts possession of the token rather than the person who authenticated. MFA protects the initial sign-in, but it does not remain attached to every subsequent request. Once issued, the token is the access mechanism. That is why replay works: an attacker who steals a valid token can present it from another device or location and inherit the original session context. In practical terms, security teams must stop thinking of MFA as a complete access control and start treating token issuance, binding, and revocation as part of the control surface.

Practical implication: Monitor token use as an identity event, not just a login event.

How refresh tokens create persistence

Refresh tokens extend the life of an authenticated session by allowing new access tokens to be minted without re-authentication. That makes them especially dangerous in incident response because password resets and MFA changes may not invalidate them immediately. In some implementations, refresh tokens can survive account changes, logout, or device removal until explicit revocation occurs. This creates a persistence layer that looks like normal access from the application’s perspective. For NHI governance, the key issue is lifecycle control: the longer a token can self-renew, the more the environment depends on timely revocation and scope management.

Practical implication: Inventory long-lived tokens and define explicit revocation triggers.

Why SaaS-to-SaaS trust expands blast radius

OAuth integrations create delegated trust between applications, which is convenient for automation but dangerous when one connected system is compromised. A stolen token may not only unlock the original account, but also inherited permissions across connected SaaS services. That creates lateral movement at the application layer, bypassing network controls and traditional perimeter assumptions. The article’s discussion of supply chain token compromise shows why NHI governance must include third-party grants, consent scopes, and integration review. The control problem is not just who logged in, but what that token can reach through delegated trust relationships.

Practical implication: Review OAuth grants and remove integrations that exceed their business need.

Threat narrative

Attacker objective: The attacker aims to maintain authenticated access without triggering MFA, then use delegated trust to reach data, APIs, and downstream environments.

1. Entry begins with AiTM phishing, malware, browser compromise, or supply chain exposure that captures a valid OAuth or session token.
2. Escalation occurs when the attacker validates token scope, enumerates connected resources, and uses delegated permissions to move across SaaS integrations.
3. Impact follows when the attacker persists through refresh tokens, exports data, or pivots into downstream customer environments.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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 exposes an identity lifecycle gap, not a login gap. The industry still overweights authentication events and underweights what happens after a token is issued. That bias leaves teams blind to replay, delegated access, and token renewal paths that operate outside the login screen. Practitioners should reframe token governance as a continuous control problem, not a one-time authentication problem.

Bearer-token trust is the new identity blast radius. Once a token can act anywhere it is accepted, the scope of damage is defined by token reach, not by the original user’s intent. That makes delegated permissions, OAuth grants, and refresh paths the most important review points in SaaS security. Teams that do not model blast radius at the token level will keep discovering compromise too late.

Refresh token persistence creates trust debt. Long-lived tokens accumulate operational convenience but reduce incident response effectiveness. Password resets and MFA resets are no longer sufficient containment steps if the environment still honors renewable access. The practical conclusion is that token revocation, scope minimization, and access expiry must be designed as first-class controls, not emergency clean-up tasks.

Phishing-resistant MFA helps, but it does not solve replay. Many organisations treat stronger MFA as the endpoint, when the bigger issue is token portability after authentication succeeds. That means identity programs need behavioral detection, device binding, and continuous access evaluation alongside MFA. The controls stack has to move from proving the user once to validating the session continuously.

Supply chain token exposure turns one compromise into many. The article’s SaaS-to-SaaS example is a reminder that non-human identity risk now travels through trust relationships, not just compromised endpoints. For practitioners, that means third-party app review and OAuth governance belong in the same program as service account and secret management. If the token can traverse ecosystems, the governance model must as well.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility, according to The State of Non-Human Identity Security.
• That same study found 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.
• For a broader control perspective, see OWASP NHI Top 10 for the access, trust, and delegation patterns that make token abuse harder to contain.

What this signals

Token theft pushes identity teams toward a more operational model of control. The programme question is no longer whether MFA exists, but whether the organisation can see token issuance, token use, and token renewal across SaaS and AI-connected systems. That is why the trust boundary has shifted from login to session governance, and why unmanaged OAuth grants now deserve the same scrutiny as stale secrets.

Ephemeral access, persistent risk: short-lived tokens reduce exposure, but they do not remove delegated trust or replay risk unless organisations also bind tokens to device or session context. The governance work therefore sits at the intersection of NHI lifecycle control and continuous access evaluation. Teams that align this with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 will have a clearer path from detection to containment.

The practical signal for enterprise programmes is that token review will become a recurring control, not a post-incident exercise. If your environment already has broad third-party OAuth exposure, the next compromise is more likely to arrive through delegated access than through a password spray. That makes app-grant governance, session telemetry, and revocation testing a standing part of identity risk management.

For practitioners

• Baseline token use against expected behavior Track token issuance, IP patterns, geolocation, device fingerprints, and session duration so abnormal replay stands out. Focus on access patterns after login rather than relying on failed authentication alerts.
• Audit OAuth grants and delegated scopes Identify unused or overprivileged integrations, then remove broad consent where the business process does not require it. Review SaaS-to-SaaS connections as part of third-party access governance, not as a one-time app inventory exercise.
• Shorten token lifetime and define revocation triggers Set explicit expiration, automate revocation on account changes, and verify that refresh tokens do not outlive the session they protect. Incident response playbooks should include token revocation steps, not only password resets.
• Use phishing-resistant authentication with device binding Reduce initial capture risk by pairing phishing-resistant MFA with device-bound credentials for privileged access. This does not eliminate token abuse, but it raises the cost of token acquisition and limits replay from unmanaged devices.

Key takeaways

• Token theft turns valid sessions into attack tools, so MFA alone no longer defines access assurance.
• The scale of the problem is already visible in Microsoft 365 breaches, frequent AiTM activity, and SaaS supply-chain spillover.
• Practitioners should treat token lifecycle, delegated scope, and behavioral detection as core IAM and NHI controls.

Key terms

• Bearer Credential: A bearer credential is a secret that grants access to whoever possesses it, without requiring proof of the original user at every request. In SaaS and cloud environments, OAuth tokens, session cookies, and similar artifacts behave this way, which makes theft and replay a direct access path.
• Refresh Token: A refresh token is a long-lived credential that can generate new access tokens without forcing the user to log in again. It increases convenience, but it also creates persistence risk because attackers can keep renewing access until the refresh token is explicitly revoked.
• AiTM Phishing: Adversary-in-the-middle phishing inserts attacker infrastructure between the victim and the real login service. The attacker relays the login in real time, captures the issued token, and bypasses MFA by stealing the authenticated session rather than guessing the password.
• OAuth Grant: An OAuth grant is the authorization a user gives an application to access data or actions on their behalf. In practice, it is a delegated trust relationship that can become an NHI risk when scopes are too broad, poorly reviewed, or left active after the business need ends.

Deepen your knowledge

Token theft, refresh token persistence, and OAuth governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building controls around bearer credentials and delegated access, it is worth exploring.

This post draws on content published by Obsidian Security: Token-Based Attacks and how attackers bypass MFA. Read the original.