OAuth tokens and SaaS supply chain risk: why IAM controls fail

At a glance

What this is: This is an analysis of OAuth tokens as persistent SaaS credentials and the ways they create hidden access paths, over-scoping risk, and supply chain exposure.

Why it matters: It matters because IAM teams often govern human logins well while missing machine-to-machine trust, which leaves NHI activity outside normal review and response paths.

By the numbers:

• The average enterprise has over 1,000 active OAuth integrations, according to Obsidian Security.
• Organizations commonly find that 60-80% of OAuth integrations can operate with reduced permissions after proper scope review, according to Obsidian Security.
• The Salesloft-Drift breach affected over 700 organizations, according to Obsidian Security.

👉 Read Obsidian Security's analysis of OAuth token vulnerabilities in SaaS environments

Context

OAuth tokens are bearer credentials that let applications access SaaS resources without repeated password checks or MFA prompts. That convenience creates an IAM blind spot when tokens persist after the original user, project, or vendor relationship has changed, because the authorization remains valid even when the business context no longer does.

For NHI governance, the issue is not whether OAuth is used, but whether organizations can inventory, scope, monitor, and revoke the tokens they issue. The Salesloft-Drift incident showed how a compromise in one integration layer can cascade across downstream SaaS tenants, which is a familiar pattern rather than an outlier in modern SaaS estates.

Most enterprises still treat OAuth connections as configuration artifacts instead of identities with lifecycle risk. That is an atypical and increasingly expensive assumption.

Key questions

Q: How should security teams govern OAuth tokens in SaaS environments?

A: Treat OAuth tokens as non-human identities with owners, scopes, expiry, and revocation requirements. Maintain a live inventory of grants, remove unused permissions, and monitor usage for anomalies. If a token can access business data without human re-authentication, it needs the same lifecycle discipline as any other privileged credential.

Q: When do OAuth refresh tokens become more risky than short-lived access tokens?

A: Refresh tokens become the bigger risk whenever they can persist beyond the original business need or bypass normal MFA and password controls. A short-lived access token limits abuse windows, but a refresh token can renew access repeatedly. That makes long-lived refresh grants the main source of durable SaaS exposure.

Q: What is the difference between OAuth token inventory and token monitoring?

A: Inventory shows which tokens exist, who owns them, and what they can reach. Monitoring shows how those tokens are actually behaving over time. Both are necessary because a complete list of tokens does not reveal abuse, and anomaly detection cannot protect what the organisation has not discovered.

Q: How can organisations reduce the blast radius of a compromised OAuth integration?

A: Limit scopes, segment critical SaaS systems, shorten refresh token lifetimes, and revoke unused grants aggressively. Then tie token activity to behavioral detection so compromise is found before it spreads across connected apps. The practical goal is to make one stolen token expose the smallest possible set of systems.

Technical breakdown

Why OAuth bearer tokens create persistent access risk

OAuth access tokens and refresh tokens behave differently, but both extend trust beyond a normal login session. Access tokens are short-lived and used to call APIs, while refresh tokens can mint new access tokens without re-prompting the user. Because the service validates possession rather than intent, a stolen token can be replayed from anywhere. That makes OAuth a bearer model, not a continuously verified identity model. The security gap widens when apps store tokens outside hardened secret stores or retain them long after the original approval should have expired.

Practical implication: Security teams should treat every active token as an NHI with its own expiry, owner, and revocation path.

How consent, scopes, and refresh flows widen the attack surface

The OAuth authorization flow creates trust at the moment of user consent, then extends it through code exchange and refresh. Users often approve scopes without understanding whether an app needs read-only access or broad write permissions. Once refresh tokens exist, access can continue even if the user changes password or leaves the company, because the token lives outside the human authentication loop. Weak state validation, broad redirect handling, and permissive consent policies increase the chance that a legitimate flow becomes an attacker-controlled access path.

Practical implication: Scope governance and periodic re-authorization matter because the original consent event is not a durable security control.

Why static inventories miss active OAuth abuse

A token inventory tells you what exists, but not whether a token is being used normally, abusively, or by an attacker. That distinction requires behavioral monitoring across API calls, geography, user agent patterns, data volume, and application relationships. In SaaS environments, malicious token use often blends into legitimate traffic because the request is technically valid. This is why posture tools alone do not close the gap. Continuous anomaly detection is the only practical way to separate expected integration behavior from compromised or over-privileged access.

Practical implication: Teams need telemetry that connects token behavior to business context, not just a static list of issued credentials.

Threat narrative

Attacker objective: The attacker seeks persistent, trusted access to downstream SaaS data and workflows without triggering normal authentication defenses.

1. entry via compromised integration provider credentials or consent phishing that yields legitimate OAuth tokens
2. escalation through refresh token use that extends access beyond the original login event and bypasses MFA enforcement
3. impact by replaying trusted tokens to move laterally across SaaS tenants and exfiltrate data at scale

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Bearer credential governance is now an NHI problem, not only an application problem. OAuth tokens behave like non-human identities because they authorize actions without ongoing human presence. That means lifecycle control, scope review, and revocation discipline must be applied with the same seriousness as service account governance. Practitioners should stop treating tokens as background plumbing and start governing them as access-bearing identities.

Ephemeral access does not eliminate trust debt. Short-lived access tokens can reduce exposure, but refresh tokens and consent grants preserve trust long after the original approval. The resulting trust debt accumulates when teams assume MFA and password policy cover the whole access path. Practitioners need controls that expire not only credentials but also the authorization assumptions behind them.

Identity blast radius is the right concept for OAuth risk. A single over-scoped integration can reach multiple SaaS applications, data sets, and business units. That blast radius is often invisible until a breach occurs because the integration looks legitimate from the platform side. Practitioners should map each token to the systems it can reach and reduce the maximum damage any one token can cause.

Static SaaS inventories are necessary but insufficient. Discovery answers what is connected, but it does not answer whether the connection is still needed, correctly scoped, or being abused. NHI governance for OAuth has to combine inventory, policy, behavioral telemetry, and revocation workflows. Practitioners should measure the time between suspicious token activity and revocation, not just the number of connections found.

The market now needs token governance that is continuous, not periodic. The dominant failure mode is not the absence of OAuth, but the absence of ongoing control after authorization. That shifts the category toward runtime monitoring, automated entitlement reduction, and lifecycle enforcement across SaaS integrations. Practitioners should demand controls that operate at the same speed as the integrations they protect.

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.
• 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 supports the case for lifecycle controls, which are covered in NHI Lifecycle Management Guide.

What this signals

OAuth governance is becoming a core part of SaaS resilience planning. The practical signal for security teams is that identity reviews must extend beyond users and service accounts to include every delegated app connection. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, the gap is structural, not procedural.

Identity blast radius should be measured, not assumed. Teams need to know how many systems any one token can reach and how quickly that reach can be revoked. That becomes more urgent when integrations span Salesforce, Google Workspace, and downstream automation layers, because one compromised grant can become a multi-platform incident.

Runtime detection should be treated as a control, not an enhancement. Static SaaS posture checks will not surface active token misuse fast enough if attackers are replaying legitimate credentials. Aligning monitoring with the NIST Cybersecurity Framework 2.0 detection and response functions helps teams translate token telemetry into containment.

For practitioners

• Inventory every active OAuth integration Build a complete list of OAuth grants, refresh tokens, scopes, owners, and connected SaaS systems. Include shadow integrations discovered outside the identity provider so the inventory reflects actual access paths.
• Reduce scopes to the minimum required Review each integration for read, write, offline access, and admin privileges. Remove broad permissions that exceed the current use case and require justification for any token that can reach production data.
• Set expiry and re-authorization rules Limit refresh token lifetime, enforce periodic re-consent for high-risk integrations, and revoke dormant grants during offboarding or vendor changes. The goal is to prevent long-lived access from surviving business context changes.
• Monitor token behavior continuously Correlate API volume, geography, user agent, and data access patterns to spot tokens that behave unlike the approved integration. Pair that telemetry with alerting and rapid revocation playbooks.
• Tie tokens to incident response workflows Make token revocation a first-class containment step in SaaS incident playbooks. If an integration provider is compromised, teams should be able to revoke related tokens quickly across all affected tenants.

Key takeaways

• OAuth tokens are NHI credentials, and they create persistent access paths that often sit outside normal password and MFA controls.
• Over-scoping and long-lived refresh grants are the main reasons a single integration can become a high-blast-radius incident.
• Security teams need inventory, lifecycle enforcement, and behavioral monitoring together, because any one of those controls alone leaves a gap.

Key terms

• OAuth Token: A credential that lets an application access resources on behalf of a user or system. In SaaS environments, the key risk is that possession often matters more than identity, so a stolen token can be replayed without passwords or MFA. Tokens therefore need ownership, scope, expiry, and revocation control.
• Refresh Token: A long-lived credential that can obtain new access tokens without asking the user to authenticate again. It is a persistence mechanism, not just a convenience feature. If it is not tightly governed, it can keep SaaS access alive long after the business need, user role, or vendor relationship has changed.
• OAuth Scope: The set of permissions granted to an application during authorization. Scopes define what the token can do, such as read data, write records, or access offline sessions. Over-scoped grants increase blast radius because the application can operate far beyond the narrow task it was meant to perform.
• Identity Blast Radius: The maximum damage a credential or token can cause if compromised. For OAuth, blast radius is determined by scopes, connected applications, data reach, and token lifetime. Reducing it is a governance goal because a single delegated grant can otherwise spread across many SaaS systems.

Deepen your knowledge

OAuth token lifecycle governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring delegated SaaS access under control, this is a practical starting point.

This post draws on content published by Obsidian Security: What are OAuth Tokens? How It Works, and Its Vulnerabilities. Read the original.