Gainsight-Salesforce OAuth incident exposes refresh-token trust gaps

At a glance

What this is: This is an analysis of the Gainsight-Salesforce OAuth incident, and its key finding is that compromised refresh tokens can turn trusted third-party access into direct Salesforce data exposure.

Why it matters: It matters because IAM, NHI, and PAM teams have to govern connected-app access as part of the identity perimeter, not as a separate SaaS concern.

By the numbers:

• More than 200 Salesforce instances may have been impacted by the compromised tokens.

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

Context

The Gainsight-Salesforce OAuth incident is a connected-app trust failure, not a Salesforce platform flaw. In plain terms, a third-party integration was able to use long-lived refresh tokens to access customer environments after the upstream access path was compromised, which is a direct identity governance problem for NHI teams.

This matters because OAuth grants often sit outside the controls teams apply to human identities, yet they can still read, write, and impersonate application behaviour. When refresh tokens outlive the people, vendors, or business purpose that originally justified them, the identity perimeter becomes much larger than the directory suggests.

That pattern is typical in SaaS-to-SaaS integrations, especially where connected apps accumulate quietly over time and are rarely re-authorised from first principles.

Key questions

Q: What breaks when a third-party OAuth refresh token is stolen?

A: A stolen refresh token can keep generating valid access tokens until it is revoked or expires, which means the attacker can keep acting as the approved integration rather than as a noisy intruder. In practice, that turns delegated access into persistent access and makes revocation speed, scope limitation, and token inventory the decisive controls.

Q: Why do delegated SaaS integrations complicate identity governance?

A: They complicate governance because the access is often granted by business users or vendor workflows, yet the blast radius reaches production data and privileged APIs. Teams must govern scopes, approval owners, and reauthorisation cycles with the same seriousness they apply to human access, because the risk lives in the delegation chain.

Q: How do security teams know if a connected app is overprivileged?

A: Look for apps that can reach more objects, environments, or actions than their business function requires, especially if they use admin users or broad OAuth scopes. If the integration cannot be cleanly described in one sentence of purpose and one sentence of reach, it is usually overprivileged.

Q: Who is accountable when a vendor OAuth grant is abused?

A: Accountability usually sits with the customer for granting and monitoring access, and with the vendor for how its own credentials, tokens, and apps are protected. The practical control point is shared visibility, because neither side can manage the blast radius alone once delegated access exists.

Technical breakdown

OAuth refresh tokens and why they are high-risk

OAuth access tokens are meant to be short-lived, while refresh tokens are designed to obtain new access tokens without asking the user or operator to reauthenticate each time. That convenience creates durable trust: if a refresh token is stolen, the attacker can continue minting valid access tokens until revocation or expiry. In connected-app environments, refresh tokens often carry the same practical power as a persistent secret, especially when they can reach customer data through delegated API scopes. The security issue is not the protocol itself, but the combination of longevity, broad scope, and poor visibility into where those grants exist.

Practical implication: Treat refresh tokens as standing non-human credentials and inventory them with the same discipline as secrets.

Connected app trust and delegated Salesforce access

A connected app creates a trust relationship between the vendor application and the customer tenant. In this case, the vendor app could pull and push data into Salesforce using delegated OAuth authorisation that was originally approved for business functionality. Once that trust relationship is abused, the attacker does not need to break Salesforce directly. They inherit the app's delegated rights, which can include highly sensitive customer records, account telemetry, and other operational data. This is why connected-app sprawl is an identity problem, not just an integration problem.

Practical implication: Map every connected app to the data and actions it can reach, then remove grants that are broader than the use case.

Token revocation, reauthorization, and integration hygiene

Revoking tokens stops active abuse, but it does not fix the underlying pattern that allowed persistent third-party access in the first place. Reauthorisation decisions matter because teams can recreate the same exposure if they reissue broad grants, use admin users, or leave stale OAuth approvals in place. The safer pattern is to collapse distributed authorisations into one controlled integration identity with tightly scoped permissions and explicit approval. That makes revocation, rotation, and offboarding operationally manageable instead of scattered across users and business teams.

Practical implication: Rebuild integrations around a single least-privileged integration identity and remove unmanaged approvals.

Threat narrative

Attacker objective: The objective was to turn trusted delegated access into durable access to customer Salesforce data and related credentials.

1. Entry occurred through previously compromised third-party credentials linked to the broader Salesloft Drift campaign, which gave the attackers a foothold into Gainsight access paths.
2. Credential access came from stolen OAuth refresh tokens that could generate new access tokens and continue authenticating into customer Salesforce environments.
3. Impact followed when the attackers used those delegated rights to pull Salesforce data directly and appear to have pursued additional credentials and sensitive records.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Refresh-token trust debt is the core failure mode this incident exposes. The problem was not a broken Salesforce platform but a delegated access model that allowed long-lived tokens to persist after upstream credentials were compromised. That is what makes the blast radius so difficult to contain: the token remains valid even when the original security assumption has already failed. Practitioners should treat every refresh token as accumulated trust that eventually has to be paid down.

Vendor access without lifecycle offboarding is a named governance failure, not a hygiene issue. This incident shows what happens when third-party NHI access is granted for business convenience but not continuously revalidated against actual need. The trust relationship outlives the operational context, so the token continues to function after the vendor or campaign state has changed. The implication is that offboarding for non-human access must be as deliberate as joiner-mover-leaver handling for employees.

Connected-app sprawl turns identity governance into a distributed control problem. When hundreds of refresh tokens are issued across users, teams, and integrations, no single review cycle has a complete picture of exposure. That fragmentation weakens visibility, revocation speed, and accountability at the same time. OWASP NHI Top 10 guidance applies here because the issue is not merely access, but unmanaged delegated access across business systems.

Least privilege for integrations only works when the integration identity is singular and bounded. The article's recommended pattern of one dedicated integration user is a reminder that multiple human-linked grants multiply failure paths. A single controlled grant is easier to monitor, revoke, and attest than a web of user-authorised approvals. Practitioners should therefore evaluate connected-app design as an access architecture question, not a convenience feature.

Refresh-token abuse is an identity perimeter problem that crosses human IAM and NHI governance. The same controls that protect humans from over-authorisation, stale access, and weak approval discipline now have to govern machine-to-machine SaaS links. That is where IAM, PAM, and NHI practice converge: the actor is non-human, but the accountability gap is still human-owned.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 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 to nearly 1 in 4 for securing human identities.
• That visibility gap is why teams should pair OAuth inventory work with the 52 NHI Breaches Analysis to understand how delegated access turns into breach paths.

What this signals

Connected-app governance is becoming the practical boundary of NHI management. As SaaS ecosystems deepen, the real control point is no longer the application login but the delegated grant behind it. Teams should expect more incidents where the breach path runs through approved integrations rather than direct platform compromise, and that shifts inventory, revocation, and offboarding into the centre of IAM operations.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the gap is not a missing dashboard but a missing governance model. In that environment, token lifecycle controls and approval ownership need to be treated as first-class identity data, not as support tickets.

For practitioners, the near-term signal is that vendor access reviews must expand beyond service accounts and API keys to include connected apps, refresh tokens, and delegated scopes. That is where the next wave of identity perimeter risk will surface.

For practitioners

• Inventory every connected app and delegated OAuth grant Create a live register of which vendor apps can reach which Salesforce objects, scopes, and environments. Include refresh-token status, approval owner, and last reauthorization date so revocation can happen quickly when a vendor credential event occurs.
• Reduce refresh-token exposure wherever functionality allows Review whether each integration truly requires refresh tokens or whether short-lived access and reauthentication can satisfy the use case. Where refresh tokens are unavoidable, scope them narrowly and document the business justification for each grant.
• Rebuild Salesforce integrations around a single integration identity Replace user-spread approvals with one dedicated least-privileged integration account per use case. Remove admin-level permissions unless the business function genuinely requires them, and avoid reusing human accounts for machine access.
• Cross-check logs and IoCs before reauthorising any app Use published indicators of compromise, API audit logs, and token activity to confirm whether the integration touched data during the incident window. Only restore access after the affected grant has been rebuilt from a clean, bounded approval path.

Key takeaways

• This incident shows that delegated OAuth access can become a durable breach path when refresh tokens are compromised and not rapidly contained.
• The scale signal is the breadth of potential exposure, with more than 200 Salesforce instances reported as possibly affected by the compromised tokens.
• The control that most directly limits this class of event is a tightly scoped, centrally owned integration identity with disciplined token inventory and revocation.

Key terms

• Refresh Token: A refresh token is a long-lived credential that can mint new access tokens without repeated user login. In identity governance terms, it behaves like durable delegated trust, so compromise or over-broad issuance can extend access well beyond the original business intent.
• Connected App: A connected app is a trusted integration between a vendor service and a customer environment, usually authorised through OAuth scopes. It matters because the app can inherit real data access, making its lifecycle, permissions, and offboarding part of the identity perimeter.
• Delegated Access: Delegated access is permission that one identity receives to act on behalf of another identity or organisation. For non-human identities, the risk is that the delegated grant can outlive the original purpose, creating a standing path into business systems if it is not tightly governed.
• Token Revocation: Token revocation is the act of invalidating a credential so it can no longer authenticate or authorise access. In practice, it is only effective when teams know where the token exists, who owns it, and what other dependent grants must be rebuilt after removal.

Deepen your knowledge

Refresh-token governance and connected-app lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team manages SaaS integrations at scale, this is a practical place to tighten the model.

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.