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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Obsidian Security's blog post: OAuth token risk in SaaS integrations can preserve access outside normal login controls and widen exposure across connected applications.

Why it matters: It matters because IAM teams often govern the user session while attackers abuse the integration layer, so NHI inventory, scope control, and revocation discipline become central to SaaS security.

By the numbers:

• According to Obsidian Security, the average enterprise has over 1,000 active OAuth integrations.
• According to Obsidian Security, organizations conducting OAuth scope audits commonly find that 60-80% of integrations have permissions exceeding operational requirements.
• According to Obsidian Security, the Salesloft-Drift breach showed tokens from an integration provider granting access to over 700 organizations.

Context

OAuth tokens are bearer credentials that let applications act on a user or system’s behalf, which means access can continue even when the original login event is long gone. In SaaS environments, that creates a governance gap between human authentication and machine-to-machine access.

The practical failure is not that organisations use OAuth. It is that integrations are often granted broad scopes, left active long after the business need changes, and rarely monitored with the same rigor as user accounts or privileged admin sessions.

The article’s central point is that SaaS supply chain risk lives in the connections between systems, where security teams have weaker visibility than they do over the applications themselves.

Key questions

Q: What breaks when OAuth tokens are treated as permanent access?

A: Permanent OAuth access turns a delegated token into standing privilege, which means a compromise can be reused until someone revokes it. That increases the chance of cross-platform data exposure, secret harvesting, and lateral movement. Organisations need identity ownership, scope review, and revocation discipline for tokens, not just for human accounts.

Q: Why do over-scoped OAuth permissions create more risk than many SSO and MFA controls can stop?

A: OAuth tokens can grant direct access to data and application functions after a user approves an app, so they often bypass the protections people associate with SSO and MFA. If an app keeps read, write, or admin privileges, it can expose documents, mailbox content, or directory settings even when authentication is strong. The risk comes from persistent delegated access, not weak login security.

Q: How do security teams know if OAuth abuse is slipping past detection?

A: The warning signs are gaps between user activity and identity telemetry. If sign-in logs look normal but browser behaviour shows unusual copy-paste, redirect, or code transfer patterns, the attack may already be in progress. Monitoring must include browser events, deprecated identity logs, and the specific application and resource IDs associated with suspicious consent activity.

Q: Should organisations treat SaaS integrations like non-human identities?

A: Yes. SaaS integrations use OAuth tokens, API keys, and service accounts that function as non-human identities, so they need discovery, ownership, expiry, and offboarding controls. If teams leave them outside IAM governance, they become dormant trust relationships that can persist for months or years.

Technical breakdown

Bearer tokens and delegated SaaS access

OAuth access tokens are bearer credentials, which means possession is enough to use them. That design removes the need to re-enter passwords or satisfy MFA for each API call, so a stolen token can be replayed directly against the resource server. Refresh tokens deepen the problem because they can mint new access tokens without user interaction. In practice, the control boundary moves from login events to token issuance, scope assignment, and revocation state. If those states are unmanaged, the token becomes a durable access path rather than a temporary delegation mechanism.

Practical implication: Treat token issuance as a governance event and enforce lifecycle ownership for every integration token.

Why OAuth tokens create SaaS supply chain exposure

OAuth tokens connect SaaS applications through trusted delegation, so one compromised integration can become a path into many downstream services. The article shows this clearly in the Salesloft-Drift case, where tokens from an integration provider were used to reach Salesforce, Google Workspace, and other connected environments. Traditional login monitoring misses this because the attacker is not breaking authentication in the usual way. Instead, they are operating inside an authorized channel that already has standing permission to move data between applications.

Practical implication: Map every third-party integration to downstream data access so token compromise can be contained by design.

Over-scoping and stale tokens as governance failures

The largest weakness is not token creation but token governance. Users frequently approve scopes they do not understand, and teams often leave long-lived or over-privileged tokens in place after the original project, employee, or vendor relationship has changed. That turns a convenience feature into persistent privilege. Static inventories alone are insufficient because they show which tokens exist, not whether their scopes are still justified or whether their behavior is normal. Continuous review must therefore combine inventory, scope minimization, and runtime detection of misuse.

Practical implication: Audit scope, expiration, and activity together rather than relying on a one-time token inventory.

Threat narrative

Attacker objective: The attacker aims to preserve legitimate-looking access across multiple SaaS tenants and extract data or operational value through trusted integrations.

1. Entry occurs when a user authorizes a third-party SaaS integration and the application receives OAuth tokens with broad delegated access.
2. Credential abuse follows when attackers steal or inherit refresh tokens from a compromised integration provider and reuse them without passwords or MFA.
3. Impact appears when the token is replayed across connected SaaS services, enabling lateral movement, data access, and long-lived persistence inside customer environments.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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

OAuth tokens expose an identity governance gap, not just an authentication gap. The article shows that the security problem begins after authentication has already succeeded, when delegated access is granted to applications that sit outside the normal user-login boundary. That means IAM programmes focused only on human sessions miss the operational reality of SaaS trust chains. Practitioners need to treat token governance as part of the identity control plane, not a side issue.

Long-lived refresh tokens create a standing privilege pattern that looks nothing like user access but behaves like it. Refresh tokens can keep reissuing access long after passwords change, employees leave, or integrations should have been retired. That makes offboarding and reauthorization as important for machine access as they are for human accounts. The practical conclusion is that token lifecycle ownership has to be explicit, time-bound, and auditable.

Over-scoped OAuth permissions are a blast-radius problem disguised as convenience. The article’s 60-80% scope audit finding points to a systemic governance issue: many integrations are granted far more access than they need. Once a token is compromised, excessive scopes turn a single delegated trust decision into cross-application exposure. The named concept here is delegated trust sprawl, and it is now a core SaaS identity risk.

Static inventories cannot govern an active token economy. Knowing that a token exists is not the same as knowing whether it is being abused, whether it still has business justification, or whether its behavior has drifted. That is why behavioral detection matters alongside inventory and revocation. Security teams should expect token abuse to look legitimate until usage patterns are correlated across applications and tenants.

SaaS supply chain compromise is now an identity problem across vendors, not within one tenant. The Salesloft-Drift case in the article shows that one compromised integration provider can create exposure across many customer environments at once. This shifts the governance question from isolated app security to shared trust management across the SaaS ecosystem. Practitioners should assume third-party access will fail somewhere and govern the blast radius accordingly.

From our research library:

• The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.

What this signals

Delegated trust sprawl: SaaS security programmes now need a separate control view for OAuth grants, because the identity provider sees user login while the risky access path sits in the integration layer.

Access review cadences built for human accounts do not solve bearer-token persistence. The control that matters is not whether a user is active, but whether a token still has a justified scope, owner, and expiry.

Security teams should assume that one compromised integration can ripple across multiple SaaS services, so blast-radius containment has to be designed into token governance rather than bolted on after an incident.

For practitioners

• Inventory every OAuth integration Build a complete register of applications, scopes, refresh token lifetimes, owners, and downstream systems for each SaaS tenant.
• Reduce scopes to the minimum required Review granted permissions against actual task needs and remove write, offline access, or admin scopes that are not operationally necessary.
• Set expiration for refresh tokens Apply maximum lifetimes and periodic re-authorization for sensitive integrations so delegated access does not persist indefinitely.
• Monitor token behaviour, not just logins Detect geographic anomalies, unusual data access volume, and unexpected user-agent patterns that indicate stolen or misused tokens.
• Revoke tokens during offboarding and vendor change Remove active OAuth grants when employees leave, projects end, or third-party relationships change so stale access does not survive accountability.

Key takeaways

• OAuth token risk is really a governance problem around delegated access, not a failure of the OAuth standard itself.
• The article shows that refresh tokens and over-scoped permissions can extend compromise far beyond the original login event.
• Discovery, scope minimisation, expiry, and behavioural monitoring are the controls that change the outcome, not one-time approval at consent time.

Key terms

• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• 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.
• Over-Scoped Integration: An over-scoped integration is a connected application that has been granted more data, object, or API access than its business purpose requires. In identity governance terms, it creates unnecessary blast radius because any compromise of the connector inherits the excess privilege.
• Behavioral Token Detection: Monitoring token usage patterns rather than only login events to identify misuse. It looks for anomalies such as unusual geography, data volume, timing, or network context that signal a legitimate token is being used in an illegitimate way.

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 building or maturing an IAM programme, it is worth exploring.