OAuth token governance is the missing control for SaaS security

At a glance

What this is: This is an enterprise guide to OAuth security that argues the real control gap is token governance after authorization, not password or MFA protection at login.

Why it matters: It matters because IAM and NHI teams now have to govern OAuth grants, refresh tokens, and third-party app behavior as durable access paths inside SaaS environments.

By the numbers:

• Microsoft's Threat Intelligence team reported a surge in OAuth-based attacks throughout 2024.
• The Salesloft-Drift incident affected more than 700 companies through downstream OAuth access.
• Google Workspace eliminated password-based authentication on May 1, 2025.
• Microsoft is phasing out Basic Authentication completely by April 30, 2026.

👉 Read Obsidian Security's guide to OAuth security and SaaS token abuse

Context

OAuth is an authorization layer, not a login control. Once a user approves an app, that app can keep using bearer tokens without triggering MFA again, which means the real NHI governance problem starts after the initial consent event. For IAM teams, the gap is visibility, review, and revocation across grants that are often created outside normal approval workflows.

The article frames a familiar SaaS blind spot: users add integrations, tokens persist, and security teams often discover the exposure only during an incident. That is typical for modern enterprise environments, not an edge case, because business workflows increasingly depend on third-party OAuth apps that outlive the reason they were approved.

Key questions

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

A: Security teams should treat OAuth tokens as standing access that must be inventoried, reviewed, monitored, and revoked like any other identity credential. The practical model is continuous governance, not one-time approval, because consented apps can keep accessing data long after the user stops thinking about them. Review scopes, owners, and behavior together.

Q: Why do OAuth attacks bypass MFA so often?

A: OAuth attacks bypass MFA because the attacker is not asking the user to log in again after the token is issued. Once consent is granted, the bearer token can be replayed without another authentication challenge. That is why consent phishing and token theft are so effective against environments that rely only on login controls.

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

A: Token inventory shows which grants exist at a point in time. Behavioral detection shows whether those grants are being used in ways that match historical patterns, such as location, ASN, scope, and data access. Inventory supports governance, but behavior is what reveals active token abuse.

Q: When does an OAuth integration become a security risk?

A: An OAuth integration becomes a security risk when it has more scope than it needs, is not reviewed regularly, or continues running after the business use case ends. The risk rises further when refresh tokens persist and no behavioral monitoring exists to detect replay, drift, or unauthorized data access.

Technical breakdown

OAuth tokens as bearer credentials in SaaS environments

OAuth tokens are bearer credentials, which means possession is enough to use them. After a user grants consent, the token can access resources without re-authentication, so MFA, SSO, and endpoint controls do not re-enter the transaction. That design is intentional, but it shifts security responsibility to token lifetime, scope, storage, and revocation. In SaaS environments, the real risk is not the protocol specification. It is the operational gap between issuing a token and continuously governing what that token can do across third-party applications, service workflows, and delegated access paths.

Practical implication: Treat OAuth grants as standing access unless you can prove otherwise, and review them with the same rigor as privileged entitlements.

Why PKCE and redirect URI validation matter

The guide centers on two core protections: Proof Key for Code Exchange, or PKCE, and exact redirect URI matching. PKCE binds the authorization request to the token exchange, which blocks code interception when a client cannot safely hold a secret. Exact redirect matching prevents attackers from steering authorization codes to malicious endpoints through wildcard or loose validation. These controls do not eliminate OAuth abuse, but they close the most common implementation paths that turn a normal authorization flow into token theft. RFC 9700 exists because those failures keep repeating in real deployments.

Practical implication: Enforce PKCE everywhere it applies and eliminate wildcard redirect handling before tokens are issued at all.

Behavioral detection versus token inventory

Inventory tells you which OAuth tokens exist. Behavioral detection tells you whether they are behaving like stolen credentials or legitimate integrations. That distinction matters because a token used from a new ASN, an app suddenly reading new data, or a refresh token being replayed can all indicate abuse even when the token itself looks valid. Static discovery is useful for baseline governance, but it cannot see compromise in motion. The operational shift is from periodic review to continuous analysis of token behavior, scope changes, and unusual data access patterns across the SaaS supply chain.

Practical implication: Use behavioral telemetry to detect anomalous token use, then pair it with revocation workflows that can act within minutes, not review cycles.

Threat narrative

Attacker objective: The attacker wants persistent SaaS access through trusted tokens that survive login protections and enable lateral movement across connected applications.

1. Entry begins when a user approves a malicious or over-permissioned OAuth application through consent phishing or an unreviewed integration.
2. Escalation occurs when the attacker reuses access or refresh tokens to bypass MFA and move through trusted SaaS relationships without new authentication challenges.
3. Impact follows when stolen tokens are replayed across downstream applications, expanding access into email, files, CRM data, and other connected systems.

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 security has become an NHI governance problem, not just an application security problem. The control plane now sits around consent, scope, token lifetime, and revocation, which are all identity decisions even when the assets are SaaS integrations. Security teams that still treat OAuth as a developer-only concern will miss the post-authentication abuse path that attackers prefer. The practical conclusion is that OAuth grants belong in identity governance and access review workflows.

Ephemeral authentication does not eliminate persistent access debt. Access tokens may be short-lived, but refresh tokens, delegated scopes, and repeated app consent create durable exposure that looks like normal business activity. That makes token governance a form of standing privilege management in disguise. Practitioners should assume the blast radius persists until tokens, grants, and connected apps are explicitly reviewed and removed.

Behavioral detection is now the deciding control for OAuth abuse. Discovery alone can answer what exists, but not whether a token is being replayed from attacker infrastructure or an app is expanding into new data paths. The named concept here is token behavior drift, meaning legitimate OAuth usage gradually diverges from expected access patterns until compromise becomes visible. Teams should build detection around drift, not just inventory.

OAuth migration timelines are forcing identity teams to absorb more SaaS trust than they planned for. As basic authentication disappears, enterprises are pushed toward OAuth for more workflows, which expands the number of tokens and consent surfaces that must be governed. That increases the value of centralized review, automated revocation, and app risk scoring. The conclusion for practitioners is straightforward: migration without governance simply replaces one legacy risk with another.

Consent phishing is succeeding because it works inside trusted workflows. Users are not being tricked into giving up passwords so much as they are being tricked into authorizing access the business has already normalized. That means awareness training alone will not close the gap. Organisations need approval controls, permission baselines, and continuous monitoring for third-party app grants.

From our research:

• 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, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which explains why post-consent governance keeps failing in practice.
• That visibility gap makes Top 10 NHI Issues a useful next step for teams rebuilding OAuth governance around review, scope control, and detection.

What this signals

OAuth governance is converging with NHI lifecycle management. As more enterprise workflows move onto OAuth because basic authentication is disappearing, teams need to manage consented access as a lifecycle problem from approval to revocation. That lifecycle lens is the right one for SaaS integrations, because the security failure usually happens after issuance, not at login. For practitioners, the immediate signal is to align OAuth review with identity governance and access review cycles.

With 1.5 out of 10 organisations highly confident in securing NHIs, the category-wide confidence gap is already visible in OAuth oversight. That gap will widen as refresh tokens, delegated scopes, and unreviewed app grants accumulate across SaaS stacks. Teams should prepare for more automation around discovery, review, and revocation, because manual token governance will not keep pace.

Token behavior drift: when legitimate OAuth use gradually diverges from expected access patterns, compromise and overreach start to look the same. Security programmes should watch for ASN changes, scope expansion, and unusual data access as routine detection signals, not edge cases. The practical response is to tie identity telemetry to SaaS behavior analytics and shorten revocation time.

For practitioners

• Inventory every OAuth grant across SaaS platforms Build a complete register of third-party apps, scopes, refresh tokens, and owner accounts across your core SaaS estate, then reconcile it against business justification and data sensitivity.
• Enforce exact redirect URI validation Require byte-for-byte redirect URI matching, remove wildcard handling, and verify PKCE is mandatory wherever public clients are in use.
• Review high-risk scopes on a fixed cadence Prioritize admin, mail, file, and CRM scopes for quarterly or faster review, with explicit removal of stale integrations and unused grants.
• Detect anomalous token behavior continuously Baseline ASN, geolocation, call volume, scope use, and data access patterns, then trigger investigation when refresh token reuse or access drift appears.
• Move revocation authority close to identity operations Give identity and SaaS operations teams a playbook to revoke tokens, disable apps, and notify owners within minutes of suspicious activity.

Key takeaways

• OAuth tokens are a governance problem because they persist beyond authentication and can be replayed without MFA.
• Visibility gaps, not protocol flaws alone, are what let malicious apps and stolen tokens move through SaaS environments unnoticed.
• The right control strategy combines exact OAuth implementation, continuous behavioral detection, and fast revocation.

Key terms

• OAuth Token: An OAuth token is a bearer credential that authorizes an application to access protected resources on a user or service’s behalf. In enterprise SaaS, the token often outlives the login event, so its scope, storage, and revocation become governance issues, not just protocol details.
• Consent Phishing: Consent phishing is a social engineering technique that tricks a user into approving a malicious or over-permissioned OAuth application. The attacker does not need the password after consent is granted, because the resulting token can be replayed until it is revoked or expires.
• Refresh Token: A refresh token is a long-lived credential used to obtain new access tokens without forcing the user to log in again. It increases convenience, but it also creates persistent access that can survive well beyond the original session and become a high-value target for attackers.
• Token Behavior Drift: Token behavior drift is the gradual divergence between normal OAuth usage and observed activity, such as new locations, new scopes, or new data paths. It is useful for detection because stolen or abused tokens often look legitimate until their behavior starts to change.

Deepen your knowledge

OAuth token governance and SaaS integration risk are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for delegated access and refresh token oversight, it is worth exploring.

This post draws on content published by Obsidian Security: OAuth Security: How to Secure OAuth Integrations. Read the original.