Salesforce-Drift OAuth token abuse exposes SaaS trust gaps

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Akeyless's blog post: Compromised SaaS tokens can turn trusted integrations into breach paths when governance is static.

Why it matters: It matters because IAM and NHI programmes have to govern SaaS tokens as live credentials with scope, rotation, monitoring, and offboarding, not as inert integration settings.

By the numbers:

• Compromised OAuth tokens in the Salesforce-Drift attack exposed sensitive data from more than 700 organizations.

👉 Read Akeyless' analysis of Salesforce-Drift OAuth token abuse and SaaS trust gaps

Context

OAuth tokens are non-human credentials that let connected applications act on behalf of an integration or workload. In SaaS environments, they often outlive the security review cycle that governs the application using them, which turns convenience into standing trust exposure.

The Salesforce-Drift case shows the governance gap clearly: if a token is stolen, the attacker inherits the application’s trust relationship and can operate inside the SaaS ecosystem without reauthenticating as a human. That makes token lifecycle, not just login security, the control boundary that matters here.

Key questions

Q: What breaks when OAuth tokens are not governed as lifecycle assets?

A: Teams lose track of who owns the access, what it can reach, and whether the permission still matches the business need. That allows stale integrations, excessive scopes, and unrevoked tokens to persist long after the original approval context has changed, creating a standing path into SaaS data.

Q: Why do compromised integration tokens create such a large blast radius?

A: They usually sit inside trusted workflows that can touch more than one system, so one stolen token can expose the original SaaS app and then lead attackers to additional secrets in cloud, chat, or automation environments. That turns a single credential loss into an ecosystem-wide identity problem.

Q: What are the signs that OAuth consent governance is failing?

A: Common signs include broad scopes granted to unfamiliar applications, app registrations that survive beyond their business purpose, and consent events that are logged but not acted on. If reviewers only see the abuse in hindsight, governance is too slow for the risk level. The control needs policy, not just audit trails.

Q: How should security teams respond when a trusted SaaS integration is compromised?

A: Start by revoking the compromised token, then inventory every related credential, service principal, API key, and downstream system that the app could reach. After that, review scopes, reissue credentials from trusted environments, and monitor for unusual API activity. The goal is to close the trust chain, not just the first entry point.

Technical breakdown

Why long-lived OAuth tokens become standing trust

OAuth tokens are designed to authorise delegated access between services, but they become dangerous when they are static, broadly scoped, and stored without lifecycle controls. In practice, the token becomes the trust object, not the user session. If the integration is compromised, the attacker does not need MFA bypass or password theft. They inherit the token’s delegated privileges and can query data, call APIs, and move laterally across the connected SaaS estate until the token is revoked or expires.

Practical implication: Treat OAuth tokens as governed NHI credentials with expiry, scope limits, and revocation paths, not as configuration data.

How supply chain access turns one integration into many systems

SaaS integrations often sit in the middle of a dependency chain that includes third-party apps, automation platforms, and downstream business processes. That means one compromised token can bridge multiple services if access is federated too loosely. The weakness is not the protocol alone, but the trust graph around it: a third-party integration may have far more reach than the team that owns it realises. The Salesforce-Drift attack illustrates how delegated SaaS access can become an ecosystem-wide entry point when inventory and governance are fragmented.

Practical implication: Map every OAuth-connected dependency and remove unowned or over-scoped integrations from production paths.

Why monitoring and rotation have to work together

Monitoring tells you when a token is being abused, but monitoring alone does not reduce the exposure window. Rotation replaces the credential so the stolen token stops working, while audit logging and anomaly detection shorten the time to discovery. In connected SaaS estates, those functions need to be coordinated because a token can be valid, active, and dangerous even when no human user is interacting with the system. The key control issue is whether the organisation can detect misuse fast enough to revoke trust before bulk data access completes.

Practical implication: Pair token rotation with immutable audit trails and alerting on unusual API patterns, especially bulk queries from unfamiliar sources.

Threat narrative

Attacker objective: The objective was to use delegated SaaS trust to access and extract sensitive data at scale without triggering normal human authentication controls.

1. Entry occurred when attackers obtained compromised OAuth tokens tied to the Salesforce-Drift integration.
2. Credential abuse followed as the stolen tokens bypassed MFA and preserved delegated SaaS access without a new login event.
3. Impact came from automated extraction of sensitive data from more than 700 organisations across the connected ecosystem.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth trust without lifecycle governance is the core failure here: The Salesforce-Drift case shows that delegated SaaS access is only as safe as the token lifecycle behind it. Once a long-lived token is issued, the control model assumes the trust relationship will stay valid and well-managed, but that assumption fails when the credential can be stolen and reused outside the original context. The implication is that organisations must govern token issuance, scope, and revocation as a first-class identity lifecycle problem.

Standing SaaS trust creates an identity blast radius: A third-party integration with broad OAuth permissions does not behave like a normal application account. It inherits business access across services, so one compromised secret can expose multiple environments and workflows at once. That is why this is not just a secrets-management issue, but a governance issue around who can extend trust into the SaaS estate and how far that trust travels.

Secrets sprawl turns SaaS integrations into hidden access paths: When OAuth tokens sit in code, app settings, or fragmented vaults, teams lose the ability to answer basic ownership questions. That is exactly the condition that makes lateral abuse easier and offboarding slower. The practical conclusion is that SaaS integrations need the same ownership, inventory, and review discipline that security teams already expect for other non-human identities.

Zero standing privilege matters because token value is time-bound: The attack demonstrates that any credential that remains valid after the task is complete is a liability, even if it was issued legitimately. Static access makes the trust assumption too durable for modern SaaS ecosystems, where integrations are constantly changing. Practitioners should view ephemeral access not as a convenience control but as the default boundary for SaaS delegation.

Named concept: identity trust drift: This case shows how a SaaS integration’s original authorisation intent drifts away from its real-world reach over time. The token still looks valid, but the surrounding dependency chain, ownership, and exposure profile no longer match the assumptions baked into issuance. Teams should treat that drift as a governance defect, not a tooling defect.

From our research library:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
• Read next: Secrets Management Buyer's Guide

What this signals

Identity trust drift: SaaS teams need to stop treating OAuth tokens as one-time setup artefacts. The moment a token’s real reach exceeds its documented owner, the programme has an identity governance problem, not just a secrets problem.

The right control model is lifecycle-based, not event-based. Issue, scope, monitor, rotate, and revoke need to be connected to the same owner and the same inventory, or the integration becomes a hidden path through the SaaS estate.

For practitioners

• Map every SaaS OAuth dependency Inventory all OAuth-connected applications, service accounts, and automation flows so teams can identify where delegated trust enters the environment and which integrations can access production data.
• Shorten token validity windows Replace long-lived OAuth tokens with short-duration credentials and revoke old tokens automatically when an integration is rotated, decommissioned, or reauthorised.
• Centralise token ownership Assign a business and technical owner to every token, including third-party integrations, so offboarding and review decisions are explicit rather than implicit.
• Monitor for unusual API behaviour Alert on bulk queries, unfamiliar source IPs, and access patterns that do not match the expected workload profile, then tie those alerts to immediate revocation workflows.

Key takeaways

• OAuth token abuse in SaaS is a governance problem because delegated access can remain valid long after its original purpose.
• The Salesforce-Drift attack exposed data from more than 700 organisations, showing how far one compromised integration can reach.
• Short-lived credentials, central ownership, and rapid revocation are the controls that shrink the blast radius when SaaS trust is abused.

Key terms

• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• 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.
• Token Rotation: Token rotation is the practice of replacing a refresh token with a new one after use and invalidating the previous token. It helps detect replay and reduces reuse risk, but it does not solve compromise on its own. Strong implementations combine rotation with atomic invalidation, telemetry, and full-family revocation.
• SaaS Trust Graph: A SaaS trust graph is the network of applications, integrations, and credentials that inherit access from one another across cloud services. It helps security teams see how one compromised token can create a much larger blast radius than the individual application suggests.

What's in the full article

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

• Step-by-step guidance for centralising OAuth tokens across SaaS and CI/CD environments
• Policy examples for automated token rotation and revocation workflows
• Implementation detail for real-time auditing and SIEM forwarding of secret access events
• Practical notes on using zero-knowledge encryption and distributed fragments cryptography

👉 Akeyless' full post covers token rotation, monitoring, and lifecycle controls for SaaS integrations.

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.