Salesforce-Drift OAuth token abuse exposes SaaS trust gaps

At a glance

What this is: This is an analysis of the Salesforce-Drift OAuth attack and the governance failures that let stolen tokens bypass MFA and move through interconnected SaaS systems.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat OAuth tokens as governed identities with lifecycle controls, not just as integration artefacts that sit outside review.

By the numbers:

• The August 2025 Salesforce-Drift OAuth attack exposed sensitive data from over 700 organizations.

👉 Read Akeyless's analysis of the Salesforce-Drift OAuth attack and token risk

Context

OAuth token security is now an identity governance problem, not just a secrets problem. When a token can access a connected SaaS application, it behaves like a non-human identity with delegated authority, and the failure mode is usually lifetime, scope, and offboarding rather than authentication strength alone.

The Salesforce-Drift incident shows how static, long-lived tokens can bypass MFA and carry trust across third-party integrations. That makes centralized visibility, rotation, and access review central to NHI governance, because the control gap sits in the token lifecycle rather than in the login flow.

Key questions

Q: What breaks when OAuth tokens are managed like static app settings?

A: Static token handling turns delegated access into standing privilege. If tokens are stored in configuration files or scattered across SaaS tools, they outlive the original trust decision and can be reused after compromise. That makes revocation slow, ownership unclear, and containment difficult once a token is stolen.

Q: Why do OAuth tokens create more risk than a normal password reset process?

A: Password resets affect a human login path, but OAuth tokens often remain valid for APIs and third-party integrations after the user has changed a password. That means the attacker can keep acting through delegated access unless the token itself is revoked. Identity teams need to govern the credential, not only the account.

Q: How do security teams know whether token rotation is actually working?

A: Look for short credential lifetimes, automatic revocation of old tokens, and no successful reuse after rotation. If access logs still show valid calls from old credentials, rotation is not functioning as a containment control. Effective programmes measure time to invalidation, not just the existence of a rotation policy.

Q: Who is accountable when a third-party integration token is abused?

A: Accountability should sit with the business owner of the integration, the IAM or NHI team that governs the credential lifecycle, and the application owner who approved the connection. Shared responsibility does not mean shared inaction. A token with delegated access needs a named owner at every stage of its lifecycle.

Technical breakdown

Why OAuth tokens become durable trust carriers

OAuth tokens are bearer credentials. Whoever holds the token can act within the permissions already granted, so the security boundary shifts from the user login event to the token's storage, scope, and expiry. In SaaS integrations, these tokens often sit in app configs, CI/CD variables, or developer tooling, which makes them easy to reuse after compromise. MFA does not help once the token is issued, because the attacker is no longer authenticating as a person. The real weakness is that the token outlives the trust decision that created it.

Practical implication: inventory every OAuth token as a governed credential with an owner, scope, and expiry.

How static secrets create persistent access paths

Static secrets create standing privilege because they remain valid until someone revokes them. In an integrated SaaS environment, that means a stolen token can continue working across API calls, automated queries, and downstream applications long after the original compromise. If tokens are not rotated centrally, defenders are forced into reactive revocation after damage is done. This is the same structural problem seen in other NHI failures: the credential survives longer than the access it was meant to represent, and that gives the attacker a usable window.

Practical implication: tie token rotation to policy and lifecycle events, not manual cleanup after alerts.

What centralized monitoring changes in token governance

Centralized monitoring turns token use into an auditable identity signal. Access logs, unusual IP addresses, bulk API queries, and abnormal session volume can reveal misuse, but only if secret access is recorded consistently and forwarded into the detection stack. Without that visibility, token abuse looks like legitimate integration traffic. The important architectural point is that secrets governance and detection must be connected. Monitoring alone does not fix exposure, but it shortens the time between first use and containment when a token is stolen.

Practical implication: log secret use at the token level and route those events into SIEM workflows for anomaly detection.

Threat narrative

Attacker objective: The attacker sought persistent access to SaaS data through trusted integrations and then used that access to extract sensitive information at scale.

1. Entry occurred through compromised OAuth tokens tied to a trusted SaaS integration, giving the attacker legitimate access to connected systems.
2. Escalation happened as the stolen tokens were used to bypass MFA and perform automated bulk queries against Salesforce data.
3. Impact followed when sensitive customer information and credentials were extracted from more than 700 organisations across the connected ecosystem.

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

OAuth tokens are non-human identities with delegated authority, not harmless integration artefacts. Once a token is issued, it can operate independently of the original login event and continue acting until revoked or expired. That makes lifecycle governance, scope review, and ownership assignment part of identity control, not separate hygiene. Practitioners should govern tokens as machine identities with explicit accountability.

Standing credential exposure window: The Salesforce-Drift pattern exists because the token remained usable long after the trust decision that created it. Static secrets were designed for environments where access could be inspected after issuance. That assumption fails when a token can be stolen, replayed, and used at scale before human review catches up. The implication is that review cycles alone do not contain bearer credentials.

Centralized control matters because SaaS trust chains are only as strong as the weakest delegated secret. When third-party integrations are allowed to store their own tokens and credentials without unified governance, compromise propagates across the ecosystem. A fragmented secrets estate turns one exposed token into multiple connected attack paths. Practitioners need to treat connected SaaS access as an identity fabric, not a series of isolated app permissions.

Detection without revocation is incomplete governance. Logging token use and flagging anomalies helps, but the operational failure in this class of breach is not just visibility. It is the time gap between detection and token invalidation. Security teams should view rotation, revocation, and monitoring as a single control loop, because any one of them on its own leaves the attacker with a usable credential.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• For a broader control model, see Guide to the Secret Sprawl Challenge, which tracks how exposed secrets move from discovery into operational risk.

What this signals

Ephemeral credential trust debt: the problem is not only how fast a secret can be issued, but how long the organisation remains exposed after it is discovered. With 64% of valid secrets leaked in 2022 still exploitable today, according to The State of Secrets Sprawl 2026, teams need revocation paths that work as quickly as detection.

OAuth governance increasingly sits alongside secrets sprawl, SaaS integration control, and workload identity in the same operating model. Security teams that already map machine identities should extend that model to delegated SaaS tokens, because the attack path is now platform-to-platform rather than endpoint-only.

The next maturity step is to connect identity review, secret rotation, and anomaly detection into one operational loop. That is the only way to make token compromise measurable before attackers finish the data extraction phase.

For practitioners

• Classify OAuth tokens as governed identities Assign each token an owner, business purpose, scope, and expiry date, then review it alongside other non-human identities instead of leaving it in app-specific settings.
• Shorten token lifetime through policy-based rotation Replace static bearer tokens with centrally managed rotation schedules that revoke old credentials automatically before they can be reused across connected SaaS tools.
• Instrument token-level anomaly detection Forward secret access logs into SIEM workflows and alert on bulk API queries, unusual source IPs, and abnormal integration traffic patterns.
• Map third-party integrations to an offboarding process When a connector is retired, changed, or replaced, remove its tokens immediately and verify that no residual access remains in upstream or downstream applications.

Key takeaways

• The core failure in the Salesforce-Drift attack was not MFA weakness alone, but the persistence of compromised OAuth tokens as reusable identity credentials.
• The scale was material, with more than 700 organisations exposed and stolen tokens used long enough to support automated data extraction across SaaS integrations.
• The control that matters most is lifecycle governance for delegated credentials, including ownership, rotation, revocation, and token-level monitoring.

Key terms

• OAuth Token: A token is a delegated credential that lets one application act on behalf of a user or service without repeating the original login. In security operations, it should be treated as a live identity artefact with scope, lifetime, and revocation requirements, not as a harmless integration string.
• Standing Privilege: Standing privilege is access that remains available by default instead of being issued only when needed. In token governance, it creates a reusable path for attackers because the credential stays valid beyond the original approval moment and often survives long enough to be abused.
• Token Lifecycle Governance: Token lifecycle governance is the discipline of issuing, tracking, rotating, reviewing, and revoking delegated credentials across their full life. It matters because a token's security value depends less on where it is stored than on whether ownership, expiry, and offboarding are enforced consistently.

What's in the full article

Akeyless's full blog post covers the operational detail this analysis intentionally leaves for the source:

• Step-by-step examples of how the platform stores OAuth tokens, API keys, passwords, and certificates in a unified vault
• Policy details for automated secret rotation across SaaS, CI/CD, and hybrid environments
• Configuration guidance for just-in-time access and zero standing privileges in connected application workflows
• Audit and SIEM integration examples for secret access monitoring and alerting

👉 Akeyless's full post covers token rotation, JIT access, monitoring, and supply chain protection in SaaS.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.