OAuth token abuse is widening the NHI attack surface in SaaS

At a glance

What this is: OAuth token abuse is a non-human identity problem in which valid integration tokens are stolen, replayed, or obtained through malicious consent to access SaaS data without reauthentication.

Why it matters: IAM and NHI teams need to treat OAuth grants, refresh tokens, and third-party integrations as privileged access paths with their own lifecycle, telemetry, and blast-radius controls.

By the numbers:

• Obsidian Security says the biggest SaaS breach of 2025 affected 700+ breached organizations through compromised third-party OAuth tokens.

👉 Read Obsidian Security's analysis of OAuth token abuse and SaaS integration risk

Context

OAuth token abuse matters because the access path is already trusted. In practice, the same mechanisms that let applications talk to each other also let an attacker move quietly once a token is stolen or consent is granted to a malicious app. For IAM and NHI governance, that shifts the focus from login events to authorization grants, token lifetime, and downstream API use.

The primary problem is not that OAuth exists. The problem is that integration tokens often outlive the user session, carry broad permissions, and are monitored less aggressively than human credentials. That pattern is typical in modern SaaS environments, which is why token abuse now belongs in the NHI security conversation rather than only in application security reviews.

Key questions

Q: How should security teams govern OAuth tokens as non-human identities?

A: Security teams should assign ownership, scope limits, expiry rules, and revocation triggers to every OAuth grant. Treat each integration token as a non-human identity with a lifecycle, because the main risk is durable delegated access rather than a single login event.

Q: Why do OAuth tokens bypass MFA in real attacks?

A: OAuth tokens bypass MFA because the attacker reuses a valid authorization artifact after it has already been issued. Once the token exists, the identity provider may see the request as legitimate, so MFA is no longer part of the transaction.

Q: What is the difference between token theft and consent phishing?

A: Token theft steals an already-issued token from storage or memory and replays it later. Consent phishing tricks a user into approving a malicious app, which causes the identity provider to issue valid tokens directly to the attacker’s application.

Q: When should organisations treat an OAuth grant as a security incident?

A: Organisations should treat an OAuth grant as an incident when the app requests excessive scopes, appears unexpectedly, or cannot be tied to a known business process. High-risk grants can create silent persistence even when no password was stolen.

Technical breakdown

Why OAuth integration tokens behave like non-human identities

OAuth identity tokens and integration tokens serve different purposes. Identity tokens support interactive sign-ins for people, while integration tokens are issued to apps, services, and third-party tools for ongoing access. In practice, the latter behave like NHI credentials because they authenticate a workload or integration rather than a person. They often persist longer, are reused across automated workflows, and can carry permissions that are much broader than a single user action. That makes scope, issuance context, and revocation mechanics more important than the login event that originally approved the grant.

Practical implication: Treat OAuth integrations as governed identities with owners, scopes, and expiry rules, not as background plumbing.

How token theft and replay bypass normal authentication controls

Token theft works because the attacker does not need to defeat the identity provider after issuance. If a valid access token or refresh token is copied from a browser, device, repository, or stored secret, the attacker can replay it directly against APIs until it expires or is revoked. Refresh tokens are especially risky because they can mint new access tokens repeatedly. Traditional MFA does not help once the token is in hand, and many detection tools miss the event because the request appears to come from an authorized integration. The failure mode is authorization reuse, not password compromise.

Practical implication: Monitor token storage locations and set aggressive revocation triggers for exposed refresh tokens.

Why consent phishing creates durable SaaS supply chain risk

Consent phishing abuses the legitimate OAuth consent flow. A user is tricked into approving a malicious application, after which the identity provider issues valid tokens directly to that app. This is dangerous because the resulting access is sanctioned by design and often looks like normal SaaS-to-SaaS traffic. If the granted scopes are broad, the attacker can read mail, call APIs, and pivot into connected services without further prompts. This is why malicious OAuth grants should be treated as supply chain events, not just phishing events.

Practical implication: Review app consent policies, restrict third-party OAuth grants, and flag unusual consent patterns as security incidents.

Threat narrative

Attacker objective: The attacker aims to obtain durable, low-noise access to SaaS data and workflows while appearing to be a trusted application.

1. Entry through malicious OAuth consent or theft of a stored access or refresh token from a trusted integration.
2. Escalation by replaying the valid token to bypass MFA and access downstream SaaS APIs with sanctioned permissions.
3. Impact through silent data access, cross-SaaS movement, and persistence via refresh-token abuse.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

OAuth token abuse is now an NHI governance issue, not a narrow authentication issue. The article shows that valid tokens can be more dangerous than stolen passwords because they preserve trust after issuance. That changes the control objective from login protection to lifecycle control over grants, scopes, and revocation. Practitioners should manage OAuth tokens as privileged NHI assets with explicit ownership and review cycles.

Ephemeral access alone does not solve token abuse if refresh rights remain broad. Short-lived access tokens reduce exposure windows, but refresh tokens and delegated grants can extend attacker dwell time far beyond the original session. The real control gap is trust persistence, not just token duration. Practitioners should focus on what can still be minted after the initial grant is gone.

Consent abuse exposes an identity blast radius that conventional MFA policies do not cover. Once a user approves a malicious app, the identity provider itself becomes the issuer of compromise. That means access review, app governance, and authorization telemetry matter as much as phishing awareness. Practitioners should treat consent policy as a frontline control for NHI risk.

Token abuse in SaaS environments shows why shadow integrations deserve the same scrutiny as shadow AI. Unmanaged apps, service connections, and automation accounts expand the attack surface without obvious inventory signals. The more integrations a business accumulates, the harder it becomes to distinguish legitimate automation from malicious persistence. Practitioners should inventory and continuously validate every third-party OAuth relationship.

Identity blast radius is the right concept for measuring OAuth risk. A single compromised grant can fan out across mail, CRM, storage, and downstream automation layers. That makes downstream access mapping and privilege reduction more useful than treating each SaaS app as an isolated control plane. Practitioners should limit how far one token can travel.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 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.
• That confidence gap is why practitioners should also review OWASP NHI Top 10 for the controls most likely to fail when tokens and agents act autonomously.

What this signals

OAuth token abuse will keep widening the gap between identity governance and SaaS reality. The practical problem is not one compromised token, but the difficulty of knowing which grants are active, who approved them, and what they can reach. When identity teams cannot map delegated access quickly, blast radius grows faster than remediation. This is where a named concept matters: identity blast radius is the distance a single grant can travel through connected SaaS systems before it is contained.

The programme implication is straightforward. Teams that already struggle with NHI inventory will find OAuth governance even harder because the evidence lives across consent logs, API telemetry, and third-party app records. According to The State of Non-Human Identity Security, only 1.5 out of 10 organisations are highly confident in securing NHIs, which suggests the control gap is structural rather than isolated.

Security leaders should align OAuth governance with least-privilege policy and continuous review, not one-time onboarding checks. That means limiting third-party consent, mapping refresh-token exposure, and setting revocation thresholds that are tied to business risk. External guidance from OWASP Non-Human Identity Top 10 reinforces the same direction: treat delegated access as a lifecycle problem, not a login problem.

For practitioners

• Inventory every OAuth grant and integration owner Build a complete list of OAuth apps, API keys, service accounts, and shadow integrations across your core SaaS stack. Require business ownership, approved scopes, and a renewal date for each grant so no integration remains unreviewed.
• Constrain refresh-token authority Reduce refresh-token lifetimes where possible, use rotation, and revoke unused grants quickly. Refresh tokens are the main path to durable persistence after an initial token theft or malicious consent event.
• Tighten app-consent policy Restrict who can approve third-party OAuth apps, require admin review for high-risk scopes, and alert on unusual consent spikes. Consent phishing succeeds when the consent screen is treated as a low-risk workflow.

Key takeaways

• OAuth token abuse turns trusted SaaS integrations into an NHI risk because valid tokens can outlast the user session and bypass MFA.
• The scale of the problem is already material, with third-party token abuse responsible for a breach that affected 700+ organisations in one incident path.
• Practitioners should respond by inventorying grants, constraining refresh tokens, and treating app consent as a governed access decision.

Key terms

• OAuth Token Abuse: The misuse of valid OAuth access or refresh tokens to gain unauthorized access without repeating the original login. In NHI terms, the token becomes the credential, so the real control problem is issuance, storage, scope, and revocation rather than passwords alone.
• Consent Phishing: A social engineering tactic that convinces a user to approve a malicious OAuth application. Once approved, the identity provider issues legitimate tokens to the attacker-controlled app, which can then access APIs and data through sanctioned delegated access.
• Refresh Token: A long-lived token that allows an application to obtain new access tokens without reauthenticating the user. It is a persistence mechanism, so if it is stolen or over-scoped, attackers can maintain access long after the original session ends.
• Identity Blast Radius: The scope of downstream systems and data that a single identity compromise can reach. For OAuth and NHI governance, it measures how far a valid grant can move through connected SaaS services before revocation or containment stops it.

Deepen your knowledge

OAuth token governance and delegated access lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to control SaaS integrations at scale, it is worth exploring.

This post draws on content published by Obsidian Security: The new attack surface, OAuth Token Abuse. Read the original.