Salesforce OAuth token abuse shows the blast radius of NHI sprawl

At a glance

What this is: This is an analysis of how abused OAuth refresh tokens in a Gainsight-Salesforce integration turned third-party access into a supply-chain style incident.

Why it matters: It matters because IAM teams need to treat SaaS-to-SaaS OAuth grants as governed non-human identities, not informal app connections with indefinite reach.

Context

OAuth refresh tokens can outlive the session or access token they mint, which makes them a durable identity asset rather than a disposable integration artefact. In this incident, the security problem was not a weakness in Salesforce itself but the trust granted to a third-party app and the credentials that preserved that trust.

That distinction matters for NHI governance because OAuth-connected apps behave like machine identities: they authenticate repeatedly, they retain access over time, and they create blast radius when ownership, approval, or offboarding is weak. A posture built only around SaaS permissions misses the lifecycle control problem at the centre of token abuse.

The article's starting position is typical of modern enterprise sprawl, not an edge case. The risk emerges wherever vendors, integrations, and long-lived refresh tokens accumulate faster than inventory and revocation practices can keep up.

Key questions

Technical breakdown

Why refresh tokens create durable delegated access

An OAuth refresh token is a long-lived credential that can mint new access tokens without re-authentication. In practice, that makes it closer to a standing delegated identity than a one-time session token. In SaaS integration chains, the refresh token inherits the permissions of the connected app and whatever account or service principal authorized it. If the token is stolen, the attacker does not need to repeat user interaction. They can keep refreshing access until the grant is revoked, which is why token lifetime and revocation path matter more than the short-lived access token itself.

Practical implication: treat refresh tokens as governed credentials with explicit lifecycle ownership, not as incidental integration state.

Why third-party OAuth grants become NHI sprawl

When many users authorize the same connected app, each grant can produce a separate trust edge, permission scope, and revocation problem. That is NHI sprawl in functional terms: distributed non-human access that is hard to inventory, hard to recertify, and easy to forget. The problem is not merely that an app can call an API. The problem is that the app's authorization persists across people, teams, and time, often outliving the business need that created it. In supply-chain style incidents, the attacker targets the weakest trusted connector rather than the core platform.

Practical implication: centralize approval and inventory for connected apps so each third-party OAuth grant has a visible owner and a documented purpose.

How connected-app trust turns into data access and credential hunting

A valid OAuth grant lets a connected app act as the authorized integration, so any compromise of the app or its tokens can translate directly into API-driven data access. In this case, the article describes attackers using refresh tokens to pull Salesforce data and appear to be seeking additional credentials and sensitive records. That pattern matters because the blast radius extends beyond the first system. Once a trusted connector is abused, the attacker can move from data access to further credential discovery, especially where integrations expose tokens, notes, or linked systems.

Practical implication: monitor connected-app activity for unusual API patterns and restrict the downstream data a third-party app can reach.

Threat narrative

Attacker objective: The objective was to abuse trusted third-party access to reach Salesforce data and expand into additional credentials and sensitive records.

1. Entry occurred through a broader Salesloft Drift campaign that had already affected Gainsight and led to compromise of internal credentials.
2. Credential access followed when attackers obtained OAuth refresh tokens used by Gainsight deployments to authenticate into customer Salesforce environments.
3. Escalation happened through token reuse, because the stolen refresh tokens could mint fresh access tokens and preserve access over time.
4. Impact was direct access to Salesforce data from victim environments, along with reported attempts to extract additional credentials and sensitive records.

Breaches seen in the wild

• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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 refresh tokens are not integration convenience, they are delegated non-human credentials with lifecycle risk. Once a third-party app can mint new access tokens, the control problem shifts from session security to credential governance. That means inventory, revocation, ownership, and scope are the real boundary conditions, not the application login itself. Practitioners should treat every refresh-token grant as an NHI with a lifecycle.

Third-party OAuth access is part of the identity perimeter, not a vendor side issue. The article's central lesson is that trusted connectors now sit inside the attack surface alongside service accounts and API keys. That expands governance from endpoint review to continuous oversight of connected-app trust, especially where multiple users have granted the same integration access. The implication is that SaaS-to-SaaS access must be governed as a first-class identity domain.

NHI sprawl creates blast radius because the organisation loses visibility into who can still act on its behalf. Stale refresh tokens, over-broad scopes, and undocumented integrations all persist after the original business need fades. The result is not just more access, but more durable access that is harder to revoke quickly when compromise is suspected. Practitioners should assume every additional grant increases the revocation burden during an incident.

Token abuse exposes a governance gap between approval and offboarding. The article shows that connected-app authorisation can survive long after the approving user, team, or vendor relationship has changed. That gap is where NHI controls fail in practice, because access reviews often focus on human users while OAuth grants quietly remain active. The practitioner conclusion is clear: offboarding for connected apps must be as deliberate as user offboarding.

Refresh-token sprawl is a named concept that now deserves its own control family. The issue is not just long-lived secrets, but long-lived delegated secrets that can be multiplied by every authorization event. Once those grants are distributed across users and environments, the organisation no longer has one integration to secure but many hidden copies of the same trust relationship. The practitioner implication is to govern authorization events as a bounded identity lifecycle, not as a one-time setup step.

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.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Key terms

• 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.
• Connected App: A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
• Token Sprawl: Token sprawl is the accumulation of too many active, forgotten, or overlapping tokens across SaaS and automation workflows. It creates visibility gaps, increases the chance of over-privilege, and makes revocation slow when an incident forces a response.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

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.