TL;DR: A third-party OAuth incident tied to Gainsight-published Salesforce apps shows how stolen refresh tokens can let attackers act with legitimate access across customer environments, according to Oasis Security. The lesson is that connected-app trust, token lifetime, and vendor offboarding are now core identity controls, not SaaS integration details.
At a glance
What this is: This is an analysis of the Gainsight-Salesforce OAuth incident, where stolen refresh tokens enabled access through trusted third-party integrations rather than a Salesforce platform flaw.
Why it matters: It matters because IAM, PAM, and NHI teams have to govern vendor-issued tokens, connected apps, and offboarding as part of the identity perimeter.
By the numbers:
- More than 200 Salesforce instances may have been impacted by the compromised tokens.
Context
The governance gap here is not platform compromise but trust delegation that outlives its original approval. In OAuth-connected ecosystems, refresh tokens can keep generating access long after the human action that first authorised them, so the control problem becomes lifecycle management for third-party access.
For identity teams, this is a connected-app and NHI issue as much as a SaaS integration issue. When a vendor uses refresh tokens to act inside customer environments, token scope, revocation speed, and offboarding discipline determine whether the integration remains bounded or becomes a standing access path.
The article positions this as a supply-chain style incident because the trusted integration path itself was abused. That makes the starting position familiar in modern SaaS estates: distributed authorisation granted for convenience, then left in place across many customer environments.
Key questions
Q: What breaks when refresh tokens are granted too broadly to third-party apps?
A: Broad refresh-token grants turn a convenience feature into standing delegated access. If the token is stolen or abused, attackers can keep minting new access tokens and act inside customer environments as the trusted integration. That breaks the assumption that OAuth access is short-lived and easy to contain, especially when many users or tenants have approved the same connected app.
Q: Why do SaaS-to-SaaS connections increase the risk of lateral movement in cloud environments?
A: Because app-to-app trust often outlives the business need that created it. When service accounts, tokens, and API integrations remain active, attackers can move through connected applications without relying on user passwords. The risk rises when visibility is weak, privileges are broad, and security teams cannot see how data and permissions propagate across the supply chain.
Q: How can security teams know whether OAuth-connected applications are actually under control?
A: They should be able to name every integration owner, every granted scope, every active token, and every revocation trigger. If any of those four elements is missing, the environment does not have real governance over delegated access, only partial visibility.
Q: Who is accountable when an OAuth integration exposes customer data?
A: Accountability is shared, but the enterprise remains responsible for the access it authorises. The business owner, security team, and platform team should each know their role in approving, monitoring, and revoking integration access. For regulated data, the organisation must also be able to show that it reviewed the access path and acted promptly when risk emerged.
Technical breakdown
Why refresh tokens are the real trust boundary
OAuth access tokens are short-lived by design, which limits how long a stolen token can be used directly. Refresh tokens are different: they are durable credentials that can mint fresh access tokens and keep a session alive over time. In a connected-app model, that makes the refresh token the practical trust boundary, because it preserves delegated access even after the original user interaction is gone. When the same integration exists across many tenants, one token class can represent broad downstream access if it is not tightly scoped and revocable.
Practical implication: Treat refresh tokens as durable credentials that need lifecycle control, not as harmless session helpers.
Connected-app authorization creates distributed NHI risk
A connected app is effectively a non-human identity path: the application acts on behalf of the vendor or integration user inside the customer tenant. That means the security problem is not only what the app can do, but how many separate authorizations exist, how they are approved, and whether they can be cleanly removed. The article’s reference to token sprawl matters because every additional grant expands the blast radius and complicates revocation. Once many users or tenants have granted access, governance shifts from account security to inventory, approval, and offboarding control.
Practical implication: Inventory every connected-app grant and reduce duplicated authorizations that create token sprawl.
Why revocation speed matters more than detection after the fact
In OAuth incidents, compromise often becomes visible only after the attacker has already used the token to pull data or credentials. That makes revocation the most time-sensitive control, because access can persist until the refresh token is revoked or invalidated. The article notes token revocation and IoC sharing, which are necessary, but the deeper mechanism is that trusted delegation lets the attacker operate as a legitimate integration until controls catch up. The faster the revocation chain, the smaller the window for data access and credential harvesting.
Practical implication: Build revocation workflows that can disable third-party OAuth access before additional access tokens are minted.
Threat narrative
Attacker objective: Use stolen delegated access to read customer Salesforce data and harvest additional credentials from trusted integration paths.
- Entry occurred through compromised third-party credentials associated with a prior Salesloft Drift campaign, which the article says later enabled access to Gainsight’s environment.
- Credential access expanded when attackers obtained OAuth refresh tokens used by Gainsight deployments to authenticate into customer Salesforce environments.
- Escalation followed because the stolen refresh tokens could mint fresh access tokens and operate as the trusted integration inside victim tenants.
- Impact included direct Salesforce data access, possible additional credential harvesting, and token revocation across affected environments.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
- 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.
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: This incident shows that OAuth refresh tokens accumulate a governance debt the moment they are granted. Their long lifetime turns convenience into persistent delegated access, and that access survives far longer than the human event that justified it. Practitioners need to treat token issuance as a lifecycle decision, not an integration setup step.
Connected-app inventory is now a perimeter control: The article makes clear that the attack surface is the approved integration itself, not just the SaaS platform. When vendors and customers both rely on the same delegated path, visibility into who can act, on whose behalf, and for how long becomes a core identity control. That shifts ownership squarely into IAM and NHI governance.
Vendor offboarding without token invalidation is incomplete: The compromised access path persisted because trusted third-party authorizations could still be used after the initial compromise chain matured. The broken assumption is that a granted integration remains safe until someone notices suspicious activity. In reality, safety depends on active lifecycle withdrawal, not passive trust.
Least privilege must be enforced at the connected-app layer: The article’s advice to use dedicated integration users and avoid broad permissions reflects a larger market truth. Access that is distributed across many users, many tenants, or broad scopes cannot be governed with the same certainty as a bounded service account. The practitioner conclusion is to reduce delegated scope before reducing response time.
Refresh-token governance is part of NHI governance: Third-party OAuth access behaves like a machine identity with human approval history, which makes it easy to misclassify. Once the token is issued, the operational question is no longer who clicked allow, but who can still act inside the tenant today. That is an NHI problem, with clear implications for inventory, offboarding, and recertification.
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
Refresh-token trust debt: The practical lesson is that delegated access has to be governed as a lifecycle asset, not an integration convenience. Once a third party can mint fresh access tokens, the question becomes how quickly that trust can be withdrawn when the relationship or security posture changes.
Identity teams should expect more incidents where the compromise path runs through approved SaaS integrations rather than the core platform. That means inventory, approval, and revocation mechanics for connected apps need to sit alongside PAM and NHI controls, especially where vendors operate across many customer tenants.
OAuth-connected access is easiest to miss when it looks like business-as-usual automation. The governance task is to identify which integrations can still act in the tenant after the human who approved them is long gone, and then reduce that exposure window.
For practitioners
- Tighten refresh-token issuance Review every connected app that can mint refresh tokens and remove the grant unless the integration truly needs long-lived delegated access.
- Collapse distributed authorizations Replace many user-granted OAuth approvals with a dedicated integration user and a single controlled grant per business use case.
- Revoke stale third-party access fast Test whether your identity team can invalidate vendor OAuth access across tenants without waiting for manual cleanup or support escalation.
- Audit token sprawl and offboarding Track which vendors still hold active refresh tokens, then remove access immediately when the business relationship ends or the app is no longer needed.
Key takeaways
- The incident exposed a trust gap in delegated OAuth access, not a flaw in the Salesforce platform itself.
- Refresh tokens created the persistence that made the compromise operationally dangerous across customer environments.
- The control that matters most is fast revocation plus tight connected-app scope, backed by a real inventory of vendor grants.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Stolen refresh tokens are the sensitive credential class at the centre of this incident. |
| NHI-03 — Vulnerable Third-Party NHI | The attack path runs through a third-party integration used across customer environments. | |
| NHI-05 — Overprivileged NHI | Broad connected-app grants and integration users can expose more customer data than the business task requires. | |
| Recommendation — Treat refresh tokens as secrets, monitor their exposure, and revoke them immediately when compromise is suspected. Review vendor integrations for excessive OAuth scope and remove third-party access that cannot be tightly governed. Constrain integration users to the minimum Salesforce permissions needed for the business use case. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes stolen credentials used to access and pull data from victim environments. |
| Recommendation — Map the incident to credential access and exfiltration so detection and response teams can hunt for the same pattern. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This incident is fundamentally about managing delegated authorizations and revoking them when risk changes. |
| Recommendation — Govern OAuth grants under PR.AA-05 and verify every third-party entitlement has an owner, scope, and revocation path. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Refresh tokens are authenticators that require lifecycle management and revocation discipline. |
| Recommendation — Apply IA-5 to manage token issuance, storage, rotation, and revocation for third-party integrations. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The incident shows how abused OAuth tokens can bypass intended authentication boundaries for API access. |
| Recommendation — Harden OAuth authentication flows and invalidate compromised tokens before they can be reused against API endpoints. | ||
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.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org