TL;DR: Token theft now lets attackers bypass passwords and MFA by abusing OAuth, session, and API tokens that remain valid after authentication, according to Obsidian Security. The security model fails when bearer credentials outlive the controls meant to protect them, making revocation, behavioral monitoring, and integration mapping operational requirements, not nice-to-haves.
At a glance
What this is: This is an analysis of token theft across OAuth, session, and API credentials, showing that stolen bearer tokens bypass MFA because they remain valid after authentication and can extend access through SaaS trust chains.
Why it matters: IAM and security teams need to treat token issuance, revocation, and integration mapping as part of access governance, because MFA alone does not contain post-authentication abuse of non-human access paths.
Context
Token theft is the abuse of bearer credentials that were issued after authentication succeeded. In SaaS environments, that means the authentication step may be strong while the authorization token becomes the weak point, because whoever holds it can act as an authenticated user or integration.
The governance gap is that many identity programmes still anchor protection at login time. Once OAuth, session, or API tokens are issued, they can outlive password resets and MFA changes unless teams explicitly manage token lifecycle, integration scope, and revocation.
This problem affects both human sessions and non-human access paths because SaaS trust chains often connect users, applications, and vendor integrations. The result is a wider blast radius than most access reviews assume.
Key questions
Q: What breaks when stolen SaaS tokens are still valid after a password reset?
A: Password resets do not reliably end a token-theft incident when the attacker holds refresh tokens, session cookies, or API keys that remain trusted by downstream services. The practical failure is that incident response focuses on the human credential while the bearer credential continues to work. Teams need explicit token revocation, not just account resets.
Q: Why do bearer tokens create more risk than MFA-protected logins?
A: Bearer tokens shift trust from the login event to the token itself. MFA can block a fake login, but it cannot stop replay of a valid token that was already issued. That means the security question becomes whether organisations can govern token lifetime, scope, and revocation with the same discipline they apply to passwords.
Q: What do security teams get wrong about OAuth and connected apps?
A: Teams often assume a delegated app is safe because it was approved once, but approval is not the same as ongoing trust. OAuth grants can outlive the original need, inherit too much scope, or become a bridge into multiple SaaS tenants. Security teams should treat each grant as a revocable access path, not a permanent integration.
Q: How should security teams respond when a trusted SaaS integration is compromised?
A: Start by revoking the compromised token, then inventory every related credential, service principal, API key, and downstream system that the app could reach. After that, review scopes, reissue credentials from trusted environments, and monitor for unusual API activity. The goal is to close the trust chain, not just the first entry point.
Technical breakdown
Why bearer tokens bypass MFA after authentication
Bearer tokens are credentials that prove prior authentication rather than re-running it. In OAuth and session models, the identity provider completes the login and then issues a token that downstream services trust until expiry or revocation. That design reduces friction for users, but it also means MFA only protects the login event, not the later use of the token. Once stolen, the token can be replayed from another device or network because possession is sufficient. The core failure mode is not weak login controls. It is the assumption that authentication guarantees the legitimacy of every later request.
Practical implication: move governance from login assurance to token issuance, revocation, and usage monitoring.
Why refresh tokens and API keys create persistence
Refresh tokens and many API keys are long-lived credentials designed to keep integrations working without repeated human approval. Refresh tokens can mint new access tokens, which makes them especially useful to attackers because password resets do not necessarily invalidate them. API keys are often even more persistent, especially when hardcoded into scripts, repositories, logs, or pipeline configuration. In both cases, the credential is the control surface. If the token survives the incident response action, so does the attacker’s access. That is why token lifecycle, not just authentication policy, defines the real exposure window.
Practical implication: classify long-lived tokens as standing access and manage them with explicit expiry, ownership, and revocation rules.
How SaaS trust chains expand the blast radius
Modern SaaS environments rely on delegated access across applications, vendors, and automations. An OAuth token issued to one integration may reach multiple connected services, which turns a single compromise into a chain of downstream access. This is why token theft is rarely confined to one app or one user. The trust relationship is the asset. When organisations do not map which integrations can reach which data sets, they cannot judge the blast radius of a stolen token or prioritise which connections deserve tighter governance and monitoring.
Practical implication: inventory OAuth relationships and map every downstream application each token can reach.
Threat narrative
Attacker objective: The attacker aims to gain persistent, low-friction access to SaaS data and connected services while avoiding authentication controls and detection.
- Entry occurs when attackers steal OAuth, session, or API tokens through AiTM phishing, vendor compromise, malware, or token leakage.
- Credential access succeeds because the stolen token is already trusted, so the attacker does not need to defeat the login flow again.
- Escalation happens when the token is reused across connected SaaS applications or refreshed into new access tokens, extending persistence across the trust chain.
- Impact is achieved through authorised-looking access to data, integrations, and administrative actions at machine speed.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Bearer credentials are the real perimeter in SaaS. Password policy and MFA still matter, but they no longer define the decisive control boundary once the platform issues tokens that can be replayed independently of the original user challenge. The security problem is now trust after authentication, not just authentication itself. Practitioners need to treat token governance as a first-class access discipline, especially where integrations and automation are involved.
Token lifecycle control is a governance problem, not just an incident-response problem. Refresh tokens and API keys behave like standing privilege when they survive password resets, MFA changes, and ordinary user offboarding. That means lifecycle ownership, expiry policy, and revocation authority belong in access governance, not only in SOC playbooks. The implication is that token accountability must be explicit before compromise happens.
SaaS trust-chain mapping is now an identity control, not an architecture nice-to-have. A single OAuth grant can fan out across several connected services, which means the blast radius of one stolen credential is determined by delegation depth, not just the issuing application. Trust-chain exposure: this is the named concept that best captures the article’s core risk, where delegated SaaS access becomes a multi-hop attack surface. Practitioners should govern the chain, not the app.
Machine-speed access changes what ‘normal’ looks like for identity monitoring. Valid tokens can drive high-volume access patterns that resemble legitimate automation, so security teams need behavioural baselines for IP, ASN, user-agent, and data-access patterns. The broader lesson is that token misuse often looks like authorised activity until the data movement pattern is understood. Detection has to move closer to usage semantics.
Non-human access paths deserve the same lifecycle scrutiny as human accounts. OAuth apps, API keys, and service-style tokens create durable access paths that often persist beyond the business relationship or the original security assumption. That aligns token governance with OWASP-NHI and the access-permission expectations in NIST CSF. The practical conclusion is simple: if a credential can live longer than the trust it represents, it needs explicit governance.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
Trust-chain exposure: the article’s central lesson is that SaaS security now depends on how delegated access propagates after authentication, not just whether the login step used MFA. If a token can be replayed outside the original session context, the identity programme has to govern authorisation drift as aggressively as authentication.
Token theft also shows why incident response and identity governance can no longer be separated cleanly. Password resets, MFA re-enrolment, and user deactivation do not reliably stop bearer-credential abuse, so the programme must treat revocation, integration inventory, and token ownership as standing controls rather than break-glass tasks.
For practitioners
- Audit all live OAuth grants Identify which integrations still hold access to production SaaS data, then remove stale or unused authorisations before they become unnoticed trust paths.
- Revoke refresh tokens during incident response Treat password resets as incomplete containment unless the associated refresh tokens, session tokens, and API keys are explicitly invalidated.
- Map integration chains and downstream reach Document which applications each token can reach so you can estimate blast radius when a vendor, connector, or automation is compromised.
- Baseline token behaviour by IP and User-Agent Flag abrupt changes in source network, autonomous system, or client string because stolen tokens often retain validity while the usage context changes.
- Shorten the life of exposed API credentials Replace indefinite API keys with tighter expiry, ownership, and rotation controls where the credential is used for machine-to-machine access.
Key takeaways
- Token theft turns valid SaaS credentials into a bypass path around MFA, which means the decisive control point moves to token issuance and revocation.
- The article shows that refresh tokens, session tokens, and API keys can survive common response actions and keep downstream access alive.
- Practitioners should map integration chains, shorten credential lifetime where possible, and treat token behaviour as an identity signal, not just an access log.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Token theft in this article begins with exposed bearer credentials and stolen tokens. |
| NHI-07 — Long-Lived Secrets | Refresh tokens and static API keys create the persistence window the article warns about. | |
| NHI-03 — Vulnerable Third-Party NHI | The Salesloft-Drift style trust-chain risk comes from compromised third-party integrations. | |
| Recommendation — Scan for leaked OAuth, session, and API tokens, then revoke any credential that appears outside its intended context. Shorten token lifetimes and replace indefinite API keys with explicit expiry and rotation controls. Inventory third-party integrations and restrict the reach of any token issued to external services. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 covers lifecycle management of authenticators, including revocation and renewal. |
| Recommendation — Apply authenticator lifecycle controls to revoke stolen tokens and manage renewal policy. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about how access permissions persist after authentication. |
| Recommendation — Review entitlements and authorisations for token-based access paths and remove unnecessary reach. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes token theft followed by movement through connected SaaS services. |
| Recommendation — Map token-theft indicators to credential access and lateral movement, then prioritise hunting across connected apps. | ||
Key terms
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
- Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
- SaaS Trust Graph: A SaaS trust graph is the network of applications, integrations, and credentials that inherit access from one another across cloud services. It helps security teams see how one compromised token can create a much larger blast radius than the individual application suggests.
- Token Revocation: Token revocation is the ability to invalidate a credential before its natural expiry when it is exposed, misused, or no longer needed. For JWTs and other NHI credentials, revocation closes the gap between detection and continued access, which is essential when a stolen token can otherwise remain usable.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org