OAuth vulnerabilities in SaaS breaches: what security teams miss

At a glance

What this is: This is an analysis of why OAuth weaknesses keep showing up in SaaS breaches, with the central finding that token-based access bypasses SSO and MFA once granted.

Why it matters: It matters because IAM and NHI teams must govern OAuth grants, token scope and third-party app risk as a standing access plane, not an authentication edge case.

By the numbers:

• The Salesloft-Drift breach affected 700+ organisations and showed how persistent OAuth tokens can extend compromise across many SaaS tenants.

Context

OAuth is a delegated authorization model, not a human login control. In SaaS environments, that distinction matters because tokens can remain valid after the original sign-in event has passed, which means identity governance has to follow the grant, the scope, and the integration lifecycle.

Obsidian Security frames the problem as a gap between protocol design and enterprise practice. RFC 9700 reflects years of breach-driven lessons, including open redirects, consent phishing, token replay, and third-party compromise, all of which turn OAuth into a durable access path if teams treat it as an authentication afterthought.

For security teams, the real issue is that OAuth expands the identity perimeter beyond users and passwords. Once an app, integration, or token is trusted, the control problem shifts from login to ongoing authorization, token handling, and third-party oversight.

Key questions

Q: What breaks when OAuth tokens are not handled correctly in client applications?

A: Client applications can fail in several ways when token handling is weak. They may keep using expired tokens, misread revocation events, or expose stored tokens to interception and theft. That leads to failed requests, broken user access, and avoidable security exposure. Good implementations validate token state, store credentials securely, and recognize when a new token must be requested.

Q: When does OAuth create more risk than it reduces in SaaS environments?

A: OAuth becomes high risk when scopes are broad, tokens are long-lived, and the organization cannot see how the credential is reused across connected apps. At that point, convenience outweighs control, and a stolen token can preserve trusted access without repeated authentication.

Q: How do teams know whether OAuth token governance is actually working?

A: Look for short token lifetimes, tested revocation, no tokens in logs, and a clean mapping from each integration to an accountable owner. If disconnected apps still retain access, or if nobody can explain which scopes are approved, the programme is functioning on paper only.

Q: Should organisations treat third-party OAuth apps as part of identity governance?

A: Yes. Third-party OAuth apps can hold valid credentials into SaaS systems, so they are effectively non-human identities with delegated access. That means ownership, approval, scope review, offboarding, and behavioural monitoring should apply to them just as they do to other privileged access paths.

Technical breakdown

Why OAuth tokens bypass SSO and MFA after grant

OAuth access is carried by bearer tokens, which means possession is enough to use them. Once a token is issued, SSO and MFA no longer sit in the request path, so reauthentication controls cannot stop replay, token theft, or abuse by a compromised integration. That is why the security boundary moves from sign-in to token issuance, scope, and lifetime. The article’s core point is that many organisations still defend the login and ignore the credential that actually governs API access.

Practical implication: Treat OAuth tokens as active credentials that need lifecycle controls, not as a one-time byproduct of authentication.

How consent phishing turns user trust into delegated access

Consent phishing abuses the authorization flow itself. A malicious app presents a legitimate-looking consent screen, the user approves permissions they do not fully understand, and the attacker receives valid access tokens under the user’s granted scopes. This is not bypassing OAuth so much as using it as designed against weak user judgment and inconsistent app governance. Pre-authorized applications make the problem worse because users never see the permission grant, which hides risk from both the user and the security team.

Practical implication: Govern app consent as a privileged control point and review which permissions users can delegate without administrative oversight.

Why third-party OAuth compromise becomes SaaS supply chain exposure

When an external integration is compromised, its legitimate tokens become the attacker’s foothold into downstream tenants. That changes OAuth from an app-level access feature into a supply chain dependency, because the blast radius extends far beyond the compromised vendor or connector. The article’s examples show that token persistence, broad scopes, and weak behavioural monitoring let attackers move through SaaS ecosystems without breaking the underlying service directly. In practice, that makes every trusted integration part of the identity attack surface.

Practical implication: Inventory third-party OAuth integrations by scope and token lifetime, then monitor them as supply chain assets with tenant-level blast radius.

Threat narrative

Attacker objective: The attacker aims to convert delegated OAuth access into durable SaaS data access and lateral reach across connected applications.

1. Entry occurs through consent phishing, compromised third-party apps, or token theft rather than password compromise.
2. Credential access is achieved when the attacker obtains a valid OAuth token or authorization code that can be replayed independently of SSO and MFA.
3. Escalation follows when stolen tokens carry broader scopes, persist through refresh cycles, or inherit access to multiple SaaS tenants.
4. Impact is sustained access to mail, files, CRM data, or administrative functions until token reuse is detected and revoked.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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 is now a standing non-human identity control plane, not an authentication side channel. The bearer token, not the login event, determines effective access once delegation is granted. That means the governance model has to track grants, scopes, rotation, and offboarding with the same seriousness used for other non-human identities. Practitioners should stop treating OAuth as a protocol feature and start treating it as a governed credential system.

Delegated access fails when organisations confuse user trust with application trust. Consent screens, pre-authorized apps, and broad scopes create a control gap where the organisation believes it is governing the user, but the attacker is actually governing the token. RFC 9700 does not create new risk; it formalises years of breach evidence. The implication is that app consent must be handled as a privileged governance decision, not a convenience setting.

Third-party OAuth exposure is supply chain risk with identity consequences. A compromised connector or SaaS app can become an attack relay into many customer environments without any direct breach of the core service. That is why the security perimeter now includes partner tokens, integration scopes, and behavioural anomalies in trusted apps. Practitioners should classify external OAuth integrations as part of their identity attack surface, not as peripheral tooling.

Token lifetime is the real blast-radius control. Long-lived refresh tokens, weak reuse detection, and broad scope grants turn a single authorization event into persistent access. The article’s incident examples show that compromise duration is often determined less by the initial exploit than by how long the token remains valid and useful. Teams should read token age, scope, and issuance patterns as indicators of governance quality, not just technical configuration.

OAuth vulnerability management belongs in identity governance, not only application security. The same environment can look compliant at login while remaining exposed at token, consent, and integration levels. That is the governance gap this article exposes: controls built around users do not automatically govern delegated machine access. The practitioner takeaway is to align OAuth oversight with IAM, PAM, and NHI lifecycle processes rather than leaving it inside app teams alone.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Delegated access is now the control boundary: OAuth changes identity governance from password-centric assurance to grant-centric assurance, which means the decisive question is who can authorise what, for how long, and through which integrations. Programmes that still anchor their model on SSO assurance will miss the access path that matters most.

The practical signal is that SaaS-to-SaaS governance now belongs in the same operating model as NHI lifecycle control. Ownership, consent review, token rotation, and offboarding have to be managed together, because the breach path is usually the integration chain rather than the human login.

If you are still validating only the account login, you are validating the wrong boundary. Behavioural monitoring of token use, scope drift, and third-party activity is the closest thing to runtime assurance in this class of risk.

For practitioners

• Govern OAuth consent as a privileged workflow Require administrative review for high-risk scopes, pre-authorised apps, and new third-party integrations so delegated access is not treated as routine end-user behaviour.
• Constrain token lifetime and reuse Set explicit expiry limits for refresh tokens, enable rotation where supported, and revoke token families when reuse or replay is detected.
• Audit redirect and grant handling Check authorization servers for exact redirect URI matching, PKCE enforcement, and removal of deprecated flows that still expose tokens.
• Monitor third-party integrations for abnormal behaviour Watch for unusual data volume, new source networks, and activity timing that diverges from the integration’s expected automation pattern.
• Classify OAuth apps as governed non-human identities Assign ownership, scope review, and offboarding responsibilities for every integration that can obtain or refresh tokens inside SaaS environments.

Key takeaways

• OAuth breaches persist because delegated tokens keep working after the initial sign-in has been secured.
• The article ties major incidents to consent phishing, token theft, third-party compromise, and long-lived refresh tokens.
• Identity teams should govern OAuth grants, scopes, and offboarding as part of the non-human access lifecycle.

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.
• Consent Phishing: A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
• 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.
• OAuth Scope: An OAuth scope is a permission string that defines what an application can do on behalf of a user. In practice, scopes set the blast radius of delegated access, because the token carries the right to read, write, or administer resources until it is revoked or expires.

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.