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, and some hold access to entire mailboxes, drives or CRM tenants. When the vendor behind one is breached, the tokens it stores become an attacker's keys to many customers at once. This guide explains how integrations get access, what makes a grant risky, the incidents that made the problem urgent, and how to govern consent, scopes, tokens and vendors. It is written for identity, SaaS platform and third-party risk teams, and for security operations staff who must detect and revoke abused grants.
Key takeaways
- A grant is a standing credential held by someone else. Its risk depends on its scopes, whether it carries offline (refresh token) access, who consented and how well the vendor protects the token.
- Vendor breaches now reach many tenants at once. Salesloft Drift, Klue and the Vercel incident via Context.ai each used OAuth access held by a SaaS or AI vendor to reach customer data.
- Consent is the control point. Restrict user consent to verified publishers and low-risk scopes, route everything else through an admin approval workflow, and publish an approved app catalogue.
- Monitor integrations as identities. Baseline each integration's API volume, source networks and objects queried, and alert on bulk exports, new credentials and new high-privilege grants.
- Rehearse revocation. A vendor-breach runbook must revoke refresh tokens, rotate keys shared with the vendor and search the data the integration could reach for secrets, not just remove the app.
How SaaS integrations get access
OAuth 2.0 (RFC 6749) lets a client application obtain an access token for a resource owner's data without learning their password; a refresh token lets it obtain new access tokens later without the user present. That design is what makes integrations convenient, and what makes a stolen refresh token valuable. Integrations reach SaaS data through five main routes, each a non-human identity.
| Route | How access is granted | Typical blast radius | Who usually approves |
|---|---|---|---|
| User-consented OAuth app | A user authorises delegated scopes for their own data | One user's mail, files or calendar | The user, subject to tenant consent policy |
| Admin-consented app | An administrator grants delegated scopes for all users, or application permissions that run with no user present | The whole tenant | Application or cloud application administrators |
| Marketplace or connected app | An app from a CRM or collaboration marketplace is installed and authorised | Objects the app's connection user can read | Platform administrators |
| Integration user or API key | A dedicated account or static key is created in one platform for another to use | Everything that account or key can reach | Platform administrators, often informally |
| Browser extension or IDE plug-in | Installed by a user with access to pages, sessions or local tokens | Sessions and secrets on the device | The user |
Microsoft's documentation draws the key line: delegated permissions are used by apps with a signed-in user present, while application permissions are used by apps that run as background services and "can be consented only by an administrator". OWASP lists the risk as NHI3:2025 Vulnerable Third-Party NHI, noting that third-party applications are "usually given wide access to sensitive material" and that detecting a breached third party "without advanced notice is near impossible". See the OAuth 2.0 and OpenID Connect Guide.
Why this is now a major attack path
| Incident | What was abused | Lesson |
|---|---|---|
| GitHub OAuth Token Breach 2022 | According to GitHub, stolen OAuth user tokens issued to Heroku and Travis CI were used to download private repositories from dozens of organisations, including npm; an AWS API key found in those repositories was then used against npm infrastructure | Tokens held by an integrator lead to code, and code leads to more secrets |
| Salesloft Drift Breach 2025 | Google Threat Intelligence Group (GTIG) reports that UNC6395 used compromised OAuth tokens for the Drift application from 8 to 18 August 2025 to export data from numerous Salesforce instances, then searched it for AWS keys, passwords and Snowflake tokens | Integration data stores are secret stores; tokens for other Drift integrations, including Drift Email, were also compromised |
| Vercel Context.ai OAuth Breach 2026 | Vercel says a compromise of Context.ai, a third-party AI tool used by an employee, let the attacker take over that employee's Google Workspace account and pivot into Vercel systems | One employee's consent to an AI tool became an enterprise entry point |
| Klue OAuth Breach 2026 | Expert Insights, citing Klue's chief executive, reports that a legacy integration credential that had not been rotated or deprovisioned led to theft of customers' OAuth tokens, which were used to generate fresh Salesforce API tokens | Unrotated vendor-side credentials expose every customer connection |
| ShinyHunters Salesforce Data Theft Campaign 2025 | GTIG describes UNC6040 callers guiding victims to approve a modified Data Loader connected app during voice phishing calls | Consent can be socially engineered in real time |
The common factors are broad scopes, long-lived refresh tokens, little monitoring of API activity by integrations, and slow revocation across many tenants. In the Drift case GTIG noted the actor deleted query jobs, but "logs were not impacted", which is why integration logging matters before an incident, not after.
Understanding OAuth risk
Score each grant on the factors below. The scope and permission-type rows carry the most weight, because they set what an attacker gets if the token leaks.
| Factor | Lower risk | Higher risk |
|---|---|---|
| Scopes | Basic profile; a single resource or user-selected files | Read or write all mail, files or CRM objects; directory or admin APIs |
| Permission type | Delegated, limited to one user | Application-level, across the whole tenant |
| Token lifetime | Short-lived access tokens only | Offline access with long-lived refresh tokens |
| Consent | Admin-reviewed through a workflow | User-granted without review, or by an administrator during a phone call |
| Vendor | Assessed, verified publisher, known security posture | Unknown, small or unverified publisher |
| Usage | Active, from expected infrastructure | Dormant, or used from VPN, Tor or unexpected cloud ranges |
Microsoft's app consent investigation guidance lists the delegated permissions it has seen misused in consent phishing (Mail.*, Contacts.*, MailboxSettings.*, People.*, Files.*, Notes.*, Directory.AccessAsUser.All and user_impersonation) and says that, based on its incident response team's observations, attackers use a combination of the first six "in 99% of the consent phishing attacks". It treats Application.ReadWrite.All, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory and other write-capable application permissions as the highest-impact set. Use these as the starting tiers for your own classification.
RFC 9700, the OAuth security best current practice, adds the protocol view: refresh tokens "represent the full scope of access granted to a certain client", so an attacker who replays one "will be able to mint access tokens". It requires that refresh tokens be bound to the consented scope and resource servers, and says they should expire if the client has been inactive for some time.
Governance controls
Consent
- Restrict user consent: Microsoft recommends allowing user consent "only for applications that have been published by a verified publisher"; its built-in low-impact policy also limits users to permissions you classify as low impact. Changing the setting only affects future consents, so review existing grants separately.
- Give users a route: enable an admin consent workflow so users can request review rather than look for workarounds. In Entra ID, reviewers can view, block or deny requests, but only Global Administrators can approve requests for Microsoft Graph application permissions.
- Restrict high-risk scopes: Google Workspace lets administrators mark apps Trusted, Limited, Specific Google data or Blocked, set services such as Gmail and Drive to Restricted, and restrict access to a predefined list of high-risk OAuth scopes for Gmail, Drive, Docs and Chat.
- Protect the approvers: Datadog Security Labs notes that users with Application Administrator or Cloud Application Administrator roles can consent to any delegated Microsoft Graph permission and are not subject to user consent policies, so they are prime phishing targets. See the Entra ID Applications and Consent Guide.
Inventory and ownership
- Export OAuth grants, service principals, connected apps, integration users and marketplace installs from each identity provider and major SaaS platform; Microsoft's guidance uses the Get-AzureADPSPermissions script to export every grant to CSV.
- Record owner, business purpose, scopes, consent type (one user or all principals), vendor, data reached and last activity.
- Review every non-Microsoft app with tenant-wide (AllPrincipals) consent, as Microsoft advises, and high-risk grants at least quarterly; remove dormant and unowned apps. See the NHI Ownership Guide.
Least privilege
- Challenge requested scopes at approval; ask vendors for narrower options or resource-specific consent.
- Use a dedicated integration user per vendor with only the objects it needs, never an administrator. GTIG recommends removing the "API Enabled" permission from Salesforce profiles and granting it only through permission sets.
- Restrict connected apps to known IP ranges where the platform allows it, as GTIG advises for Salesforce.
Third-party risk
- Assess how vendors store customer tokens, how they rotate their own integration credentials and how fast they will notify you.
- Write token revocation, notification timelines and log access into contracts. See the Third-Party Risk Management (TPRM) Guide and the Vendor Security Assessment Template.
AI tools and agents as OAuth clients
AI assistants, meeting tools and agent platforms are now the fastest-growing group of OAuth clients, and they ask for broad scopes because their value depends on reading mail, documents and calendars. The Cloud Security Alliance's research note on the Vercel incident says Context.ai's app had been granted "Allow All" permissions by at least some users, and argues that vendor assessments can miss the grant itself. Treat AI tools as high-risk integrations: discover them, route them through admin consent and give them the narrowest scope that delivers the use case. See the Shadow AI Discovery Guide and the Third-Party AI Risk Guide.
- Agent front ends can host phishing: Datadog's CoPhish research showed a Copilot Studio agent's "Login" button could be configured to send users to a malicious OAuth app and exfiltrate the resulting token, from a genuine Microsoft domain. See CoPhish 2025.
- MCP uses OAuth too: for HTTP transports, the Model Context Protocol authorisation specification builds on OAuth 2.1 and requires clients to send a resource parameter (RFC 8707) naming the MCP server the token is for, an audience restriction in line with RFC 9700. See the MCP Security Guide and the AI Agent Authorisation Guide.
Detection and monitoring
NIST CSF 2.0 has an outcome for exactly this problem: DE.CM-06, "External service provider activities and services are monitored to find potentially adverse events". In practice that means treating each integration's connection user or service principal as an identity with a behavioural baseline.
| Signal | Where to find it | Why it matters |
|---|---|---|
| New consent with high-risk scopes, or admin consent | Microsoft 365 audit log "Consent to application" events, checking whether admin consent was given; the Google Workspace accessed apps list | Consent phishing and shadow AI adoption |
| New credentials or secrets added to an existing app | Identity provider audit logs | Persistence through a trusted app |
| Bulk queries or exports by an integration user | Salesforce Event Monitoring, including UniqueQuery events; SaaS API logs | The Drift and UNC6040 pattern of mass export |
| Integration traffic from new networks | SaaS login and API logs compared with the vendor's published ranges | GTIG's Drift indicators included Tor exit nodes and cloud hosting addresses |
| Unusual user agents on API calls | API access logs | GTIG listed "Salesforce-Multi-Org-Fetcher/1.0" and python-requests among Drift indicators |
| Dormant grant suddenly active | Grant inventory joined to sign-in and API logs | Old grants are rarely watched |
MITRE ATT&CK tracks the techniques as T1528 Steal Application Access Token and T1550.001 Application Access Token, and its mitigations include auditing all OAuth applications and their permissions to establish a baseline. Microsoft notes that audit entries can take from 30 minutes to 24 hours to appear and that retention depends on licence, so check both before you need them. See the ITDR Guide and the Token and Session Security Guide.
Revocation runbook for a vendor breach
- Identify: list every grant, connected app, integration user, API key and webhook secret associated with the vendor across all platforms, including integrations you did not know about (Drift Email as well as Drift for Salesforce).
- Revoke: revoke refresh tokens and sessions, disable the app or service principal, and rotate every key or secret shared with the vendor. Token revocation endpoints (RFC 7009) let a client invalidate tokens it holds; in a vendor breach you also need the platform-side revocation that removes the grant.
- Search the exposed data for secrets: GTIG advised Drift customers to search Salesforce objects for strings such as AKIA, snowflakecomputing.com, password, secret and key, and to rotate anything found.
- Scope: review audit logs from the relevant period for data accessed by the integration, searching for published indicators (IP addresses, user agents, app IDs such as the OAuth client ID Vercel published).
- Assess: decide data exposure and notification obligations with legal and privacy teams.
- Reconnect deliberately: only after the vendor confirms remediation, with narrower scopes, IP restrictions and a named owner.
Vercel's own advice is a reminder for step 2: deleting a project or account "is not sufficient to eliminate risk", because compromised secrets still work until they are rotated. See the Identity Incident Response Playbook and the Secrets Management Guide.
Framework mapping
An indicative NHI Mgmt Group alignment, checked against the published control lists; CIS references are at control level.
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 |
|---|---|---|---|---|---|
| Inventory of apps and grants | ID.AM-02, ID.AM-04 | CM-8, SA-9 | A.5.9, A.5.23 | 2, 15 | NHI3 |
| Consent policy and approval | PR.AA-05 | AC-6, CM-11 | A.5.15, A.5.18 | 6 | NHI5 |
| Token lifetime and protection | PR.AA-01, PR.AA-04 | IA-5, SC-23 | A.5.17, A.8.5 | 5 | NHI7 |
| Vendor assessment and contracts | GV.SC-05, GV.SC-06, GV.SC-07 | SA-9, SR-6, SR-8 | A.5.19, A.5.20, A.5.22 | 15 | NHI3 |
| Monitoring integration activity | DE.CM-06, DE.AE-03 | SI-4, AU-6, AC-2(12) | A.8.15, A.8.16 | 8 | NHI3 |
| Removing dormant grants | ID.AM-08 | AC-2(3) | A.5.18 | 5, 6 | NHI1 |
| Vendor-breach response | RS.MI-01, GV.SC-08 | IR-4, IR-4(10) | A.5.24, A.5.26 | 17 | NHI3 |
Common failure patterns
- Removing the app but not the tokens: uninstalling an integration in one console while refresh tokens, API keys and webhook secrets shared with the vendor stay valid elsewhere.
- Consent settings changed, old grants kept: tightening user consent only affects future consents; years of earlier grants remain until someone reviews them.
- Integration data never treated as a secret store: support cases and CRM notes hold pasted keys and passwords, which is what UNC6395 searched for in the Salesloft Drift Breach 2025.
- Vendor credentials never rotated: the Klue OAuth Breach 2026 was reported to trace back to a legacy credential that had not been rotated or deprovisioned.
- Shadow AI consent: an employee connects an AI tool with broad scopes to a corporate account, outside procurement, as in the Vercel Context.ai OAuth Breach 2026.
- Admins left outside policy: consent policies apply to users while application administrators, who can consent to anything delegated, are not given phishing-resistant MFA or extra review.
- No integration baseline: without normal volumes and source networks per integration, a day of bulk exports looks like ordinary API traffic.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Grants with a named owner and purpose | Accountability across the integration estate | Up, towards 100% |
| High-risk grants (tenant-wide or write scopes) reviewed in the last 90 days | Whether reviews happen where it matters | Up |
| Grants unused for 90 days or more | Dormant attack surface | Down |
| Consents made outside the approval workflow | Effectiveness of consent policy | Down |
| Integrations with an activity baseline and alerting | Detection coverage for DE.CM-06 | Up |
| Time from vendor-breach notice to full revocation and rotation | Response readiness | Down |
| Critical vendors with token-handling and notification clauses | Contractual coverage | Up |
See the Identity Security Metrics Guide.
Implementation roadmap
| Phase | Actions | Exit criteria |
|---|---|---|
| First 30 days | Export all grants from the main identity provider and top three SaaS platforms; restrict user consent to verified publishers and low-impact permissions; enable the admin consent workflow; revoke obviously unused or unknown high-risk apps | A complete grant list for core platforms; new high-risk consents need approval |
| Days 31 to 90 | Assign owners; classify scopes into risk tiers; build alerts for new high-risk consents, new app credentials and integration bulk exports; restrict connected apps by IP where supported; write the vendor-breach runbook | Every high-risk grant owned; detections live; runbook approved |
| Days 91 to 180 | Extend inventory to all SaaS platforms, extensions and AI tools; add token and notification clauses to critical vendor contracts; run a tabletop of a vendor token breach; start quarterly grant reviews | Quarterly review cycle running; one rehearsal completed; contract coverage tracked |
Practitioner checklist
- Restrict user consent to verified publishers and low-impact permissions, and enable an admin consent workflow.
- Restrict high-risk scopes for untrusted apps in Google Workspace and equivalent platform settings.
- Inventory OAuth grants, connected apps, integration users and extensions across the identity provider and SaaS estate.
- Assign an owner and business purpose to every grant; remove dormant and unowned apps.
- Review every tenant-wide grant and every grant with write or directory scopes at least quarterly.
- Use dedicated, least-privilege integration users, never administrators, and restrict them by IP where possible.
- Give application administrators phishing-resistant MFA and extra review of their consents.
- Baseline integration API activity and alert on bulk exports, new networks and new app credentials.
- Route AI tools and agent platforms through admin consent with the narrowest workable scopes.
- Assess vendors on token protection and include revocation and notification obligations in contracts.
- Maintain and rehearse a vendor-breach revocation runbook that includes searching exposed data for secrets.
Standards and references
- OWASP: NHI3:2025 Vulnerable Third-Party NHI
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- IETF: RFC 6749 The OAuth 2.0 Authorization Framework
- IETF: RFC 7009 OAuth 2.0 Token Revocation
- MITRE ATT&CK: T1528 Steal Application Access Token
- MITRE ATT&CK: T1550.001 Application Access Token
- Microsoft Learn: Configure how users consent to applications
- Microsoft Learn: App consent grant investigation
- Google Workspace Admin Help: Control which apps access Google Workspace data
- Google Threat Intelligence Group: Widespread Data Theft Targets Salesforce Instances via Salesloft Drift
- GitHub: Security alert: attack campaign involving stolen OAuth user tokens issued to two third-party integrators
- Vercel: April 2026 security incident
Related NHI Mgmt Group resources: SaaS Security Guide · Shadow AI Discovery Guide · NHI Authentication Guide · Top 10 SaaS Security Risks · Third-Party Risk Management (TPRM) Guide