OAuth and SaaS integration breaches: what connected app attacks teach defenders

When an attacker steals a token that a SaaS integration already holds, they arrive as a trusted application, and your MFA, SSO and login alerts never see them. This guide draws on the OAuth and SaaS integration breaches in the NHI Mgmt Group breach database to show the pattern that repeats across them: a vendor holds standing tokens for many customer tenants, the vendor is compromised, and the tokens are replayed at scale. It is written for identity, SaaS security and third-party risk teams who own connected apps in Salesforce, Google Workspace, Microsoft 365 and GitHub. Each case links to its full breach analysis; this page focuses on the shared lesson and the controls and steps that would have shortened or stopped each one.

Key takeaways

• The route is small but the blast radius is not. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) classifies 15 breaches as OAuth / SaaS integration and 20 as abusing an OAuth token, yet single cases such as Salesloft Drift reached hundreds of organisations.
• The customer's controls are bypassed by design. A refresh token or app secret is presented by the vendor's client, so phishing-resistant MFA on your users does nothing to stop its replay.
• The weak point is usually upstream. Tokens were taken from the vendor's GitHub, AWS environment or employee laptop, not from the victim's tenant, so your exposure depends on how every integrator stores what you granted it.
• Age and forgotten grants make it worse. Gainsight's stolen tokens were two to eight years old, and Klue's entry point was a token left active after an abandoned pilot.
• Inventory and behaviour baselines are what work. The report's control for this route is to inventory third-party OAuth grants and integrations, scope them down and revoke what is unused or unowned; detection then rests on per-app baselines of IP, user agent, API version and query volume.

What the breach data shows

The State of NHI & AI Agent Breach Report 2026 counts 15 breaches whose route in was an OAuth or SaaS integration, and 20 in which an OAuth token was among the identities abused. The report's year table shows the combined supply chain / OAuth share rising to 42% of 2026 breaches, from 29% in 2025. Its lesson for Salesloft Drift is the lesson for the whole class: "Inventory every connected app and integration token, with its owner, scopes and expiry."

The cases below are the ones in the database where the integration token, not a user password, was the key that opened customer data.

The connected app pattern, step by step

Across these cases the same five-step chain appears. Seeing it as a chain matters because each step has its own control owner, and most organisations only own the last two.

1. Consent creates a standing credential. An admin or user approves an app once. The provider issues a refresh token (Salesforce, Google, GitHub) or the vendor authenticates with its own client secret or certificate (Entra ID multi-tenant apps). Either way, access continues with no human present.
2. The vendor concentrates tokens for many tenants. Drift, Gainsight and Klue each held tokens for a large customer base in one environment. GTIG described one stolen Drift credential as giving access to tokens for any Drift-linked organisation.
3. The vendor is breached through another NHI. A GitHub account or personal access token (Drift, Klue), an AWS environment (Context.ai, Heroku), or an undisclosed route to an app secret (ConnectWise). This is often credential chaining: one machine credential leads to the store of others.
4. Tokens are replayed from attacker infrastructure. Requests come from new IPs and tools. In Klue, defenders saw a Python-urllib user agent and Salesforce API v59.0 where the app normally used v64.0.
5. Bulk collection, then a hunt for more secrets. Attackers paged through CRM objects and searched the exports for AWS keys, passwords and Snowflake tokens. Cloudflare rotated 104 API tokens found in its own Salesforce data after Drift.

Step 5 is why secrets pasted into support cases and CRM notes turn an integration breach into a cloud breach. See the SaaS and OAuth App Governance Guide for the governance model behind steps 1 and 2.

Five lessons that repeat

1. Grants outlive their purpose

Klue's entry token came from a 2022 pilot that was abandoned. Gainsight's oldest stolen token dated from October 2017 and only about 23% of the 285 still existed in Gainsight's own systems. Midnight Blizzard used a legacy test app. Every one of these was valid long after anyone needed it. The fix is an expiry and an owner on every grant, and a deprovisioning step in the offboarding of any vendor, pilot or tool.

2. Scope at consent decides the damage

The Context.ai grant was "full access" to a corporate Google account. The ConnectWise backup app held tenant-wide read and write access to mail, files and Teams chats, and related service principals could assign themselves directory roles. Backup, CRM sync and AI productivity tools tend to ask for broad scopes, and reviewers tend to approve them because the product needs to work. Ask for the narrowest scope the feature needs, and for Exchange-style application roles, scope to specific mailboxes where the platform allows it.

3. Shadow and personal grants are integrations too

Vercel was not a Context.ai customer. One employee signed up for a consumer AI app with a corporate Google account, and that personal grant became the path in. User consent to unvetted apps is a supply chain decision made without a reviewer. See the Consent Phishing and Illicit OAuth Grants Guide.

4. Upstream code access is a tenant credential

In Drift and Klue the first stolen credential was for GitHub, not for any customer system. Write access to an integration's code or deployment lets an attacker harvest tokens as they are used. Ask vendors how their source control and CI tokens are scoped and rotated, not only how they encrypt stored refresh tokens.

5. The data you store in SaaS is part of the blast radius

After Drift, the attacker's first move with the exports was to search for credentials. The same happened with secrets shared by email in Midnight Blizzard. Keeping secrets out of tickets, CRM records and mail is what stops an integration breach from becoming the next breach.

Controls that would have helped

For platform-specific review steps see How to review Salesforce connected apps and integration users, How to audit GitHub Apps and OAuth apps in an organisation and the Entra ID Applications and Consent Guide.

A phased programme

1. Week 1 to 2, inventory. Export connected apps and OAuth grants from each major platform: Salesforce Connected Apps OAuth Usage, Google Workspace third-party app access, Entra ID enterprise applications and their permissions, GitHub organisation OAuth apps and GitHub Apps. Record owner, scopes, grant date, last use and the integration user.
2. Week 2 to 4, revoke the easy wins. Remove apps with no owner, no use in 90 days, or a finished pilot. Pilot the revocation on one business unit first, tell app owners, and keep the export so you can re-consent quickly if something breaks.
3. Month 2, restrict consent. Turn off or limit user consent to unverified apps, route requests through admin approval, and define high-risk scopes that always need security review.
4. Month 2 to 3, constrain the survivors. Set refresh token expiry, IP ranges where the vendor supports them, and least-privilege integration users. Test each change in a sandbox org or tenant before production.
5. Month 3, detect. Build per-integration baselines in your SIEM from platform event logs, and add alerts for new app credentials, new app role assignments and bulk query patterns.
6. Ongoing, rehearse the vendor breach. Run a tabletop where a named integrator announces a breach: who revokes, how fast, what else you rotate. The OAuth Token Theft Incident Playbook covers the response detail.

Small and large organisations

• Small teams: start with the native consoles in your two or three main platforms, restrict user consent, and keep a single spreadsheet of grants with owners. That alone would have surfaced the dormant and personal grants in these cases.
• Large organisations: integrations number in the thousands. Use a SaaS security posture or NHI discovery tool to pull grants continuously, tie each grant to a vendor record in third-party risk, and make token expiry a contract term. See the NHI Discovery Guide.
• Accept or tighten: IP restrictions and short token lifetimes can break integrations whose vendors use shared cloud egress or do not handle re-authorisation well. Where a vendor cannot support them, compensate with tighter scopes and stronger monitoring, and record the risk.

Detection and measurement

• Salesforce: API usage by connected app and integration user, Login History for OAuth flows, and Event Monitoring for API and bulk API events where licensed.
• Google Workspace: OAuth token audit events for grants, revocations and activity by client ID.
• Microsoft Entra ID: service principal sign-in logs, and audit events for "Add service principal credentials", "Add app role assignment to service principal" and consent to application.
• GitHub: organisation audit log entries for OAuth app access and repository cloning by integration tokens.

Metrics that show the programme is working:

• Percentage of third-party grants with a named owner and a review in the last 12 months.
• Number of grants unused for 90 days or more (target: trending to zero).
• Median and maximum refresh token age per platform.
• Percentage of high-risk integrations with IP restrictions or sender constraints.
• Time from a vendor breach notice to revocation of all its tokens, measured in exercises.

Framework mapping

Common failure patterns

• Revoking the app but not what it could reach: after Drift, the exposed data held further secrets. Rotate anything stored in the affected records.
• Rotating some credentials and calling it done: the database shows repeat breaches when one credential is missed, as in the Cloudflare Thanksgiving breach after Okta.
• Reviewing only admin-consented apps: the Context.ai grant was one user's.
• Treating test tenants as out of scope: Midnight Blizzard started in a legacy test tenant.
• Trusting vendor egress without checking: IP allow-lists only help if the vendor publishes and keeps to them.

Practitioner checklist

• Export every connected app and OAuth grant from Salesforce, Google Workspace, Entra ID and GitHub this month.
• Give each grant an owner, a purpose and a review date; revoke those without.
• Restrict user consent and require admin approval for high-risk scopes.
• Set refresh token expiry and IP restrictions where the platform and vendor support them.
• Baseline each integration's IPs, user agents, API versions and volumes, and alert on change.
• Alert on new app credentials, new app role assignments and consent grants.
• Remove secrets from CRM records, tickets and mail, and rotate any found.
• Write and rehearse a vendor revocation runbook with a target time.
• Ask key vendors how their source control and cloud credentials that guard your tokens are scoped and rotated.

Standards and references

• NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• IETF: RFC 7009 OAuth 2.0 Token Revocation
• MITRE ATT&CK: T1528 Steal Application Access Token
• MITRE ATT&CK: T1550.001 Application Access Token
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: the SaaS and OAuth App Governance Guide, the OAuth Refresh Token Rotation and Expiry Guide, the OAuth Token Theft Incident Playbook and the NHI Ownership Guide.