Salesforce OAuth token abuse shows the blast radius of NHI sprawl

At a glance

What this is: This analysis explains a Salesforce OAuth incident involving Gainsight-connected apps and shows how compromised refresh tokens can extend attacker reach into customer environments.

Why it matters: For IAM and NHI teams, the issue is not just token theft but the governance gap created when third-party OAuth access becomes a standing trust path.

👉 Read Oasis Security's analysis of the Gainsight Salesforce OAuth incident

Context

OAuth integrations extend identity trust beyond the core application boundary. When a third-party app can hold refresh tokens, the risk is no longer limited to the vendor’s tenant because those tokens can mint new access and preserve access far longer than intended. That makes this an NHI governance problem as much as a SaaS integration issue.

The article describes a supply-chain style incident in which Gainsight-connected Salesforce access was implicated, with Salesforce revoking tokens and alerting customers. That starting point is typical of modern NHI exposure: attackers look for the least visible trust relationship, not the loudest system, and use it to reach higher-value data.

For practitioners, the core lesson is that connected apps need the same scrutiny as service accounts and API keys. If a business process depends on delegated OAuth access, the security team should treat it as an identity asset with lifecycle, scope, and revocation requirements.

Key questions

Q: How should security teams govern third-party OAuth access for SaaS integrations?

A: Treat third-party OAuth grants as NHI assets with owners, scopes, and lifecycle rules. Require approval for high-risk permissions, inventory refresh-token use, and define revocation triggers for staff changes, app changes, and anomalous activity. The goal is to make delegated access visible enough to review and fast enough to remove.

Q: When does a refresh token become a privileged access problem?

A: A refresh token becomes privileged access when it can continuously mint new access tokens for valuable systems without repeated human approval. At that point, it behaves like a standing credential. If the token can reach customer data, admin functions, or broad APIs, it should be controlled with the same rigor as other privileged identities.

Q: What is the difference between short-lived access tokens and refresh tokens in identity risk?

A: An access token is usually time-limited and meant for immediate API calls, while a refresh token is a longer-lived grant that can obtain new access tokens. The security impact is very different. Losing an access token may be temporary, but losing a refresh token can preserve access until the underlying grant is revoked.

Q: How can organisations reduce the blast radius of compromised SaaS integrations?

A: Reduce scope, reduce duration, and reduce the number of systems a single integration can reach. Use dedicated integration identities, approve only the permissions the workflow actually needs, and revoke grants that are inactive or difficult to justify. Continuous inventory matters because you cannot protect what you cannot enumerate.

Technical breakdown

Why refresh tokens change the risk model for OAuth connections

OAuth access tokens are designed to be short-lived, but refresh tokens are long-lived grants that can be exchanged for new access tokens without repeated user interaction. In SaaS integrations, that distinction matters because the refresh token effectively becomes a persistent machine credential. If attackers obtain it, they do not need to keep reusing the original user session. They can continue authenticating as the app or integration until the grant is revoked or expires. This is why delegated OAuth access should be governed as NHI, not as a one-time application permission.

Practical implication: Inventory refresh-token grants separately and treat them as standing credentials that require explicit ownership, rotation triggers, and revocation playbooks.

Why connected apps create hidden identity sprawl

Connected apps often distribute access across many business teams and tenants, which makes the identity surface wider than the admin console suggests. Each authorization can create a separate trust relationship, and each relationship may persist after staff changes, integration changes, or scope creep. The result is token sprawl: multiple active grants, uneven privilege levels, and weak visibility into which integration can reach which data. In practice, the sprawl problem is less about a single bad token and more about the accumulation of unmanaged delegated access across the environment.

Practical implication: Map every connected app to a named business owner, approved scopes, and a documented offboarding path for dormant grants.

How attacker reuse turns delegated access into data access

Once an attacker controls a trusted integration token, the attack path often looks legitimate from the application’s point of view. That allows the actor to query data, pull records, and potentially search for additional credentials or secrets in adjacent systems. The important failure mode is not only initial compromise but trust reuse: the platform continues to accept calls from an identity that appears authorized. This is why OAuth incidents frequently blur the line between application abuse and identity compromise, especially when the integration has broad read permissions.

Practical implication: Monitor OAuth activity for unusual volume, scope usage, and endpoint patterns that do not match the integration’s normal business function.

Threat narrative

Attacker objective: The attacker’s objective was durable access to customer Salesforce data through trusted OAuth grants, not a one-time login.

1. Entry occurred through compromised third-party credentials tied to a prior campaign that gave attackers access to Gainsight-related systems.
2. Escalation followed when the attackers obtained OAuth refresh tokens used by connected apps to authenticate into Salesforce environments.
3. Impact was the ability to retrieve Salesforce data through trusted integration paths and search for additional sensitive records.

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

Delegated OAuth access is now part of the NHI perimeter. When third-party apps hold refresh tokens, the trust boundary moves beyond the SaaS product and into the identity fabric connecting systems. That means IAM teams can no longer treat connected apps as a separate admin problem. The governance model has to include issuance, scope review, monitoring, and revocation for every delegated grant.

Refresh-token trust debt is the hidden control gap in SaaS integrations. Long-lived refresh tokens accumulate because they are operationally convenient, not because they are risk-free. The more integrations an enterprise permits, the more it inherits dormant access that can survive personnel changes and app sprawl. The practitioner takeaway is direct: every refresh token should have a clear owner, purpose, and removal condition.

Token revocation is necessary but insufficient without lifecycle control. Revoking active credentials after an incident stops the immediate exposure, but it does not fix why the grant existed in the first place. If the organization cannot inventory, classify, and review connected-app access, the next incident will follow the same path. Security teams need to move from incident cleanup to identity lifecycle governance.

Identity blast radius: the real measure of integration risk. The important question is not whether a vendor integration exists, but how far it can reach if abused. Connected apps with broad scopes, weak approval controls, and poor logging can turn a single delegated identity into enterprise-wide exposure. Practitioners should assess every OAuth grant by its blast radius, not just by its business value.

NHI governance must expand from secrets to sessions to grants. Secrets rotation alone does not address delegated access patterns where tokens are minted, refreshed, and reused across multiple systems. The field needs a more complete control set that includes approval workflows, monitoring, and periodic reauthorization. Teams that keep governance limited to static secrets will miss the most common SaaS identity failure modes.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• For a broader attack-pattern view, compare this issue with The 52 NHI breaches Report to see how identity exposure turns into real-world compromise.

What this signals

Identity blast radius now matters more than application ownership. The practical risk is not that a third-party integration exists, but that it can still act long after the original approval decision. When delegated access persists, the attack surface is governed by revocation speed, scope discipline, and review cadence rather than by the security posture of the SaaS app itself.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is signalling that connected-app governance is becoming a distinct control domain. Teams should expect more pressure to document who approved each grant, why the scope exists, and how quickly it can be removed.

Trust debt in OAuth grants: every persistent refresh token represents a deferred governance decision. Security programmes should move these grants into standard access review, incident response, and offboarding processes so that SaaS integrations are treated as living identities, not static technical settings.

For practitioners

• Inventory every connected OAuth app Build a live register of third-party apps, scopes, owning teams, and the systems each grant can reach. Include refresh-token usage, reauthorization dates, and a removal owner for dormant integrations.
• Constrain refresh-token issuance Require an explicit business justification before allowing refresh tokens, and block offline access where the integration does not truly need persistent reauthentication. Short-lived access should be the default.
• Review delegated scopes against business need Compare granted scopes with actual usage and remove permissions that are broader than the integration requires. Reapprove any high-risk scopes through a formal access review.
• Set revocation and reauthorization playbooks Document how to revoke tokens quickly, who approves reauthorization, and what control checks must happen before a connected app is trusted again. Test the runbook during normal operations, not only during incidents.

Key takeaways

• Third-party OAuth grants can function as long-lived NHI credentials when refresh tokens remain valid after the original approval event.
• The main control gap is not just token theft, but the inability to inventory and govern the blast radius of delegated access.
• Teams should pair revocation playbooks with lifecycle governance so connected apps can be reviewed, constrained, and removed on a routine basis.

Key terms

• Refresh Token: A refresh token is a long-lived credential that can obtain new access tokens without repeated human login. In SaaS and API integrations, it often functions like a persistent machine credential, which makes theft or misuse materially more dangerous than a short-lived access token.
• Connected App: A connected app is a third-party integration that is allowed to access another platform through delegated permissions. In practice, it creates an identity relationship that can outlive the original user session and must therefore be governed like any other non-human identity.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and privileges that can be reached if a credential, token, or integration is misused. It is a practical way to judge whether an NHI control failure is isolated or capable of becoming enterprise-wide exposure.
• Token Sprawl: Token sprawl is the accumulation of many active or forgotten OAuth grants, API tokens, or service credentials across teams and systems. It increases the chance that one weak or stale authorization can survive long enough to be abused during an incident.

Deepen your knowledge

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

This post draws on content published by Oasis Security covering the Gainsight Salesforce OAuth incident: The Gainsight - Salesforce OAuth Incident: What Happened and What to Do Next. Read the original.