TL;DR: Salesloft Drift OAuth tokens were used to access Salesforce and Gmail, and WideField says the incident appears broader than the original Salesforce path, with activity tied to malicious IPs and downstream discovery of stored secrets, according to WideField Security. The breach shows that connected app trust and token retention remain weak points in identity governance.
At a glance
What this is: This analysis of the Salesloft Drift compromise shows how stolen OAuth tokens extended access beyond Salesforce into Gmail and exposed additional secrets in downstream environments.
Why it matters: IAM, IGA, and PAM teams need to treat third-party connected apps as governed access pathways, because token reuse and poor offboarding can turn one compromise into multi-app exposure.
Context
OAuth-connected applications create a delegated access path that can outlive the moment a user first consented to it. In this case, the issue is not just initial compromise but the persistence of access once tokens were already in circulation across SaaS environments.
Salesloft Drift connected to resource environments such as Salesforce, Gmail, and Microsoft through OAuth flows, which means a single application relationship could affect multiple tenants and data sets. That makes connected-app governance a lifecycle problem, not a one-time approval problem.
WideField Security argues that the incident showed broader exposure than the original Salesforce path, and that assessment is typical for SaaS-to-SaaS access chains where token scope, storage, and revocation are handled unevenly.
Key questions
Q: What breaks when a connected app token is stolen?
A: When a connected app token is stolen, the attacker authenticates as the app rather than as a person, so MFA and user login checks often never trigger. The result is app-level access to data and APIs that can look legitimate in logs. The right response is to revoke the token, trace dependent grants, and treat the token as the real identity boundary.
Q: Why do third-party SaaS integrations increase identity risk in CRM environments?
A: They connect external applications directly to customer data, making the integration itself part of the identity attack surface. If scopes are broad, ownership is unclear, or revocation is slow, a compromised connector can expose contact data, business context, and downstream trust relationships.
Q: How can security teams tell whether OAuth access is too broad?
A: Look for apps that can read sensitive records, search wide data sets, or access more business functions than the integration needs. Broad scopes, stale grants, and app-to-app links into customer data are the clearest signals that token access is exceeding its intended boundary. If a token can support secrets hunting, it is already too permissive.
Q: Should organisations prioritise token revocation or password resets after suspected compromise?
A: Token revocation usually comes first when the incident involves OAuth, refresh tokens, API keys, or other delegated access. Password resets help only if the attacker depended on interactive login. When the compromise path includes connected apps, the priority is to cut off every issued credential and consented integration before restoring user access.
Technical breakdown
How OAuth tokens extend third-party app access
In OAuth 2.0, a connected app receives access and refresh tokens after the user or administrator grants consent. Access tokens are short-lived, but refresh tokens can be used to obtain new access tokens without re-prompting the user, which is why token theft is so consequential. When a third-party integration stores tokens on its own side, compromise of that service can expose delegated access across every connected tenant or account. In this incident, that model is what allowed Drift access to continue after the initial theft. Practical implication: govern OAuth connections as live credentials, not as static integrations.
Practical implication: Treat every connected app grant as a credentialed trust relationship with its own lifecycle and revocation path.
Why token storage inside a connected app increases blast radius
If a SaaS integration caches refresh tokens, the attacker does not need the user’s password or MFA prompt to keep operating. The risk grows when the integration touches multiple target apps because one stolen token set can become a pivot point into different data stores. The article describes Salesforce access, Gmail access, and later discovery of credentials stored inside SaaS data, which is a classic blast-radius expansion pattern. The underlying failure is not only compromise, but the concentration of delegated access in a third-party service. Practical implication: map which tokens each integration stores, where they are held, and what each token can reach.
Practical implication: Inventory token-bearing integrations by downstream reach, then prioritise the ones that can span email, CRM, and admin workloads.
How insecure secrets storage turns OAuth abuse into broader compromise
Once an attacker can query SaaS content through valid tokens, the next step is often discovery of embedded credentials or operational secrets. The article notes AWS access keys, VPN credentials, and Snowflake credentials stored in Salesforce by some affected organisations. That is not the root cause of the Drift incident, but it is a compounding control failure because it turns a single identity compromise into access to other platforms. NHI governance has to include secrets hygiene inside business applications, not just in vaults and CI/CD pipelines. Practical implication: look for stored secrets in SaaS records as a post-compromise amplification path.
Practical implication: Remove credentials from business applications and treat SaaS data stores as potential secret-exposure locations during incident review.
Threat narrative
Attacker objective: The attacker aimed to turn stolen delegated access into persistent visibility across business systems and further credentials that could widen compromise.
- Entry occurred through compromise of the Salesloft Drift platform, where attackers obtained OAuth tokens tied to connected applications.
- Credential access then shifted to valid token use against Salesforce and Gmail, allowing the actor to operate as an authorised integration rather than forcing direct authentication.
- Escalation followed when the actor discovered additional secrets inside customer environments, creating access paths into AWS, VPN, and Snowflake systems.
- Impact was broader SaaS and downstream environment exposure, with the compromised app trust relationship enabling multi-application data theft.
Breaches seen in the wild
- GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.
- 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 and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Connected-app governance is now a lifecycle control, not an onboarding control: OAuth consent creates durable delegated access that can remain dangerous long after the original business need changes. In this case, the important fact is not the app relationship itself but the failure to treat it as an identity asset with an offboarding path. Practitioners should read this as a governance problem spanning approval, monitoring, and revocation.
Identity supply chain risk is the right mental model for SaaS-to-SaaS access: third-party apps cache access relationships, and compromise of the middle layer can expose many downstream systems at once. That is why connected apps deserve the same scrutiny as privileged accounts and service credentials. The practitioner conclusion is to model every integration by what it can reach, not by what it appears to be.
Stored secrets inside business applications create identity blast radius: once an attacker can read SaaS content, credentials left in tickets, notes, or records become secondary footholds. This is a governance gap in how organisations separate operational data from secret material. The implication is straightforward: SaaS data stores must be treated as potential secret reservoirs, not just collaboration systems.
Refresh-token persistence is the weak point that makes connected-app abuse durable: short-lived access tokens do not eliminate the risk when refresh tokens and session grants survive across time and environments. The underlying control problem is that a delegated identity can outlast the intent that created it. Practitioners need to think about revocation latency as a core risk variable.
Vendor-side compromise changes the trust boundary for everyone using the integration: when the application provider is breached, the affected organisation inherits an access problem it did not directly create. That does not absolve the customer of governance responsibility; it means the trust model must assume the provider can become a compromise amplifier. Security teams should therefore validate revocation, logging, and consent controls against third-party failure modes.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
What this signals
Connected app trust needs to be governed like privileged access: once a third-party app can reach customer data, the security team has to treat it as a standing access path with explicit issuance, review, and revocation controls. That is especially true when refresh tokens allow the relationship to persist beyond the original approval window.
Identity blast radius is the right measure of SaaS integration risk: the real question is not how many apps are connected, but how much downstream access each token can unlock if the provider or integration is compromised. That makes consent scoping, inventory accuracy, and revocation testing the controls that matter most.
Stored secrets inside SaaS platforms widen the impact of every delegated access breach: if an attacker can read business records, notes, or cases, those records may become a bridge into cloud, VPN, or data warehouse access. Teams should assume business applications can become secret repositories unless they actively remove that material.
For practitioners
- Revoke all Drift connected app grants Remove every Salesloft Drift and Drift Email OAuth connection, then reauthorise only after verifying that existing tokens were actually invalidated and not merely hidden from view.
- Review third-party app inventories by downstream reach Classify each connected app by the systems it can reach, the scopes it holds, and whether it can access mail, CRM, calendar, or admin data across tenants.
- Search business applications for embedded secrets Inspect Salesforce records, cases, notes, and other SaaS content for exposed AWS keys, VPN credentials, Snowflake credentials, and similar secrets that could extend compromise.
- Tighten OAuth consent and refresh-token policies Limit user consent for third-party apps, shorten token lifetimes where possible, and require admin review for integrations that request broad or tenant-wide access.
- Update revocation runbooks for connected apps Test how quickly Security Operations can terminate sessions, revoke access, and confirm token invalidation when a connected app is suspected of compromise.
Key takeaways
- The compromise shows that OAuth-connected apps can become durable access channels when token storage and revocation are weak.
- WideField Security reported abuse in both Salesforce and Gmail, plus discovery of stored credentials such as AWS keys and VPN secrets in some environments.
- The control problem is connected-app lifecycle governance, including fast revocation, narrow consent, and aggressive cleanup of secrets stored inside business applications.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The incident centres on a third-party integration whose compromise exposed downstream apps. |
| NHI-07 — Long-Lived Secrets | Refresh tokens and cached OAuth grants made the abuse durable across sessions. | |
| NHI-02 — Secret Leakage | The article shows stored AWS and VPN secrets inside SaaS records, which expanded impact. | |
| Recommendation — Review third-party integrations under NHI-03 and remove any app whose compromise would expose multiple systems. Shorten OAuth token lifetimes and verify refresh-token revocation paths under NHI-07. Scan business applications for embedded secrets and purge exposed credentials under NHI-02. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token issuance and revocation are the core control failures in this compromise pattern. |
| Recommendation — Apply IA-5 to manage OAuth tokens, enforce revocation, and validate authenticator lifecycle outcomes. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack used stolen tokens to access data and pull additional secrets. |
| Recommendation — Map the incident to TA0006 and TA0010 and hunt for token abuse followed by data collection. | ||
Key terms
- OAuth Refresh Token: An OAuth refresh token is a long-lived credential that lets an application request new access tokens without asking the user to log in again. In practice, it behaves like a reusable access key, so compromise can create persistent access until the token is revoked or expires.
- 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.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
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 July 4, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org