OAuth App Governance: Securing SaaS Integrations

Every time someone clicks "Allow" on a consent screen, a new non-human identity is created: an OAuth grant that lets a third-party application reach your data, often indefinitely. SaaS-to-SaaS integrations, marketplace apps, AI tools and browser extensions accumulate these grants by the thousand. Some hold access to entire mailboxes, drives or CRM tenants. When the vendor behind one is breached, its stored tokens become an attacker's keys to many customers at once. This guide explains OAuth app and SaaS integration risk, the incidents that have made it urgent, and how to govern consent, scopes, tokens and third-party integrations.

Key takeaways

An OAuth grant is a standing, delegated credential held by a third party. Its risk depends on its scopes, whether it includes offline (refresh token) access, who consented and how well the vendor protects it.
Recent supply chain breaches, including Salesloft Drift, Klue and Vercel via Context.ai, used stolen OAuth tokens to reach data in many organisations at once.
Restrict user consent for high-risk scopes, maintain an approved app catalogue and review grants continuously.
Have a revocation runbook ready for when a connected vendor is breached, including refresh tokens and API keys, not just app removal.

How SaaS integrations get access

User-consented OAuth apps: a user authorises an app to act on their behalf within the scopes requested.
Admin-consented apps: an administrator grants an app access across the organisation, often with broad application permissions.
Marketplace and connected apps in CRM, collaboration and productivity platforms.
Integration users and API keys created in one SaaS platform for another to use.
Browser extensions with access to pages and session data.

Each is a non-human identity. OWASP lists the risk as NHI3 Vulnerable Third-Party NHI in its Non-Human Identities Top 10.

Why this is now a major attack path

Salesloft Drift (August 2025): OAuth tokens held by an AI chatbot integration were stolen and used to access Salesforce data across hundreds of customer organisations.
Klue (June 2026): OAuth tokens held by a SaaS platform on behalf of its customers were exposed.
Vercel and Context.ai (April 2026): a third-party AI tool connected by an employee became the route to customer data.
GitHub repositories via Heroku and Travis CI tokens (2022): stolen OAuth tokens issued to integrators were used to download private repositories.
Microsoft OAuth phishing (2022) and CoPhish (2025): attackers tricked users into consenting to malicious apps.

The common factors: broad scopes, long-lived refresh tokens, limited monitoring of API activity by integrations, and slow revocation across many tenants.

Understanding OAuth risk

Factor	Lower risk	Higher risk
Scopes	Read basic profile; single resource	Read/write all mail, files, CRM objects; admin APIs
Permission type	Delegated, limited to one user	Application-level, across the whole tenant
Token lifetime	Short-lived access only	Offline access with long-lived refresh tokens
Consent	Admin-reviewed	User-granted without review
Vendor	Assessed, known security posture	Unknown, small or unverified publisher
Usage	Active, expected	Dormant, or used from unexpected infrastructure

Governance controls

Consent

Restrict user consent to verified publishers and low-risk scopes; require admin approval for anything broader.
Provide a quick approval workflow so users are not pushed to workarounds.
Publish an approved app catalogue.

Inventory and review

Export all OAuth grants, service principals, connected apps and integration users from identity providers and major SaaS platforms.
Record owner, business purpose, scopes, users, vendor and last activity.
Review high-risk grants at least quarterly; remove dormant and unowned apps.
See the Shadow AI and AI Agent Discovery Guide for AI-specific discovery.

Least privilege

Challenge requested scopes during approval; ask vendors for narrower options.
Use per-integration service identities in SaaS platforms, not admin users.
Limit application-level permissions to specific resources where the platform supports it.

Monitoring

Monitor integration API activity: new source IP ranges, unusual query volumes, bulk exports and access outside normal patterns.
Alert on new high-privilege grants, new credentials added to existing apps and consent to unverified apps.
Use platform features to restrict integrations to known IP ranges where available.

Third-party risk

Assess vendors on how they store and protect customer tokens, their incident notification commitments and their own NHI security.
Include token revocation and notification obligations in contracts.

Revocation runbook for a vendor breach

Identify every grant, integration user, API key and token associated with the vendor across all platforms.
Revoke refresh tokens and sessions, disable the app or service principal, and rotate any API keys or secrets shared with the vendor.
Review audit logs from the relevant period for data accessed by the integration.
Assess data exposure and notification obligations.
Reconnect only after the vendor confirms remediation, with narrower scopes where possible.

Practitioner checklist

Restrict user consent to low-risk scopes and verified publishers.
Inventory OAuth grants, connected apps and integration users across your identity provider and SaaS estate.
Assign owners and business purposes; remove dormant and unowned apps.
Minimise scopes and avoid admin-level integration users.
Monitor integration API activity and new high-risk grants.
Assess vendors on token protection and include revocation obligations in contracts.
Maintain and rehearse a vendor-breach revocation runbook.

Standards and references

OWASP Non-Human Identities Top 10 (2025): NHI3 Vulnerable Third-Party NHI
RFC 9700: OAuth 2.0 Security Best Current Practice
RFC 6749: The OAuth 2.0 Authorization Framework
MITRE ATT&CK T1528: Steal Application Access Token

SaaS-to-SaaS and OAuth App Governance Guide