Klue’s OAuth token theft exposes SaaS supply chain access risk

At a glance

What this is: Attackers compromised Klue’s OAuth tokens and abused a trusted Salesforce integration to extract CRM data across multiple enterprise environments.

Why it matters: It matters because SaaS integrations now behave like standing non-human identities, so IAM teams need visibility into scopes, revocation, and downstream blast radius.

👉 Read Obsidian Security’s analysis of the Klue Salesforce OAuth token attack

Context

SaaS supply chain risk is an identity problem when a trusted integration can act with the same authority every time its token is presented. In this case, the primary control gap was not a compromised password or a broken perimeter, but an OAuth trust relationship that persisted beyond normal scrutiny in Salesforce-connected environments.

For IAM and NHI practitioners, the relevant question is how to govern third-party integrations whose access is approved once and then forgotten. OAuth tokens, scoped SaaS apps, and integration accounts need the same lifecycle discipline as other non-human identities, because once the token exists, the platform treats it as the integration itself.

This is typical of modern SaaS supply chain abuse: the attacker does not need to defeat authentication in the usual sense, only to inherit trusted access already granted to a vendor integration.

Key questions

Q: What breaks when a stolen OAuth token is used against a trusted integration?

A: The trust model breaks because the system still sees a valid credential, even though the actor behind it is no longer trustworthy. In practice, stolen delegated access can bypass interactive authentication and continue until revocation or expiry, which is why connected app tokens need ownership, monitoring, and fast containment.

Q: Why do dormant SaaS integrations create so much identity risk?

A: Dormant integrations remain dangerous because they often keep valid secrets or delegated consent after the business process ends. If the permissions include read, write, or admin-like actions, a forgotten integration becomes a standing non-human identity that can be abused without alerting the original owner.

Q: How do security teams know if OAuth sessions are being abused?

A: Look for repeated token redemptions, unfamiliar geolocation, device changes, and abnormal application access immediately after a successful login. Those signals often reveal misuse that conventional sign-in alerts will miss. Correlating identity provider, application, and proxy logs gives the clearest view of session abuse.

Q: Who is accountable when a third-party integration exfiltrates CRM data?

A: Accountability is shared across the business owner of the integration, the SaaS security team, and the vendor that issued or relied on the token. Governance frameworks should require named ownership, periodic access review, and clear offboarding for every connector that can reach sensitive records.

Technical breakdown

How OAuth tokens become standing integration identity

OAuth tokens let a SaaS application act as a trusted integration without re-authenticating on every request. In practice, the platform treats the token as the identity of the connected app, not the person or system currently using the access path. That creates a durable non-human identity with scoped permissions, background execution, and limited human visibility. If the token is stolen, the attacker inherits whatever Salesforce scopes were granted to the integration, even when login activity originates from infrastructure that has nothing to do with the legitimate vendor footprint.

Practical implication: treat every OAuth token as a governed non-human identity with explicit ownership, scope review, and revocation paths.

Why SaaS supply chain abuse scales across tenants

A single compromised integration can reach many enterprise environments because SaaS vendors reuse the same app pattern across customers. The attack surface is therefore not just the victim tenant, but every tenant where the integration was authorized. This is why SaaS supply chain incidents create multiplicative blast radius: one trust relationship can expose account data, contact records, opportunity details, and adjacent systems that consume the same CRM data. The security problem is less about one broken system and more about the distribution model of trusted third-party access.

Practical implication: map which tenants, scopes, and datasets each integration can reach before an incident forces the inventory.

How infrastructure deviation reveals abused integration access

The article points to a key detection pattern: login activity from infrastructure inconsistent with the legitimate vendor footprint. For integrations, behaviour baselines matter as much as credentials because the token may still be valid even when the source environment is wrong. That is a classic SaaS access-violation signal. When identity, source infrastructure, and normal query patterns diverge, the token may still authenticate, but the operational context no longer matches the trusted integration model.

Practical implication: pair token revocation with source-environment anomaly detection and query logging across connected SaaS apps.

Threat narrative

Attacker objective: The attacker sought to steal CRM data at scale by inheriting trusted third-party access rather than breaking into each tenant directly.

1. Entry occurred when attackers obtained Klue’s OAuth tokens and used them to authenticate as the trusted Salesforce integration account.
2. Escalation followed through mass queries against CRM records across multiple enterprise tenants, using the scoped access already granted to the integration.
3. Impact was bulk CRM data exfiltration, with downstream exposure for phishing, competitive intelligence, and adjacent system compromise.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach — OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

NHI Mgmt Group analysis

SaaS integrations are non-human identities, not just app connectors. When an OAuth token authorises a third-party integration, it becomes a durable identity with standing access and broad tenant reach. That means governance must treat integration accounts as lifecycle-managed actors with owners, scopes, and revocation triggers. The practitioner takeaway is simple: if you do not inventory and certify integrations, you do not govern the identity plane they create.

Trusted integration access creates identity blast radius debt. Each approved SaaS connector accumulates hidden exposure because it can reach sensitive records long after the original business justification fades. This is not just poor hygiene, it is a structural governance debt created by over-scoped and under-reviewed third-party access. The practical conclusion is that blast-radius mapping must become a routine identity control for CRM-connected SaaS estates.

OAuth trust assumptions fail when source infrastructure is outside the intended footprint. The model assumes the integration presents a stable operational context that matches the authorised vendor environment. That assumption breaks when stolen tokens are used from unrelated infrastructure, because the platform still sees a valid identity even though the runtime context has changed. The implication is that identity governance must validate provenance, not only token validity.

Exfiltration via trusted SaaS routes is now a governance problem, not a perimeter problem. The attacker did not need to defeat Salesforce authentication or exploit a product vulnerability because the abuse path already existed in the approved integration layer. That shifts responsibility toward continuous integration oversight, not one-time security review. Practitioners should expect more attacks that live entirely inside legitimate access paths.

Standing third-party access without active offboarding is the failure mode this breach exposes. Once a vendor token exists, it can outlive staff changes, business changes, or even a vendor incident unless there is explicit lifecycle control. This is the same control gap that appears across NHI programmes when access is granted once and never revalidated. The lesson is to treat third-party access as perishable identity, not permanent entitlement.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader breach lens, The 52 NHI breaches Report shows how trusted non-human access repeatedly becomes the point of failure.

What this signals

Identity blast radius is now the right lens for SaaS governance. The real risk is not only whether an integration is authorised, but how much data and how many tenants it can reach before anyone notices. Teams that already map privileged paths should extend that discipline to every OAuth connector, service account, and app installation that can query customer data.

The operational signal is provenance, not just permission. If the source infrastructure for an integration changes, or if query behaviour shifts outside the normal tenant footprint, the access model has drifted even when the token remains valid. That is where integration monitoring and revocation workflows need to be tied together.

For practitioners

• Revoke and reissue exposed OAuth grants Identify every Salesforce OAuth grant associated with Klue or similar integrations, revoke the existing token grants, and reauthorize only after confirming scope, owner, and business need.
• Build a full SaaS integration inventory Create a living inventory of every connected application, the scopes it holds, the data it can query, and the business owner responsible for ongoing review.
• Baseline integration source infrastructure Track the normal hosting providers, IP ranges, and query patterns for each integration so deviations from the legitimate vendor footprint are detectable quickly.
• Map blast radius before the next advisory Document which tenants and datasets each SaaS connector can reach, then prioritise the highest-value integrations for revocation testing and access review.

Key takeaways

• Klue’s token theft shows that a trusted integration can become a large-scale data exfiltration path without a traditional perimeter breach.
• The scale evidence is multi-tenant by design: one compromised OAuth relationship can affect multiple enterprise environments at once.
• Security teams should treat SaaS connectors as lifecycle-managed identities, with scope review, source baselines, and rapid revocation built into governance.

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.
• SaaS Supply Chain: A SaaS supply chain is the network of third-party applications, integrations, and delegated permissions that connect cloud services to each other. It creates operational efficiency, but it also creates inherited trust paths where a compromise in one system can quickly affect many others.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Integration Footprint: The normal infrastructure, API behaviour, and data access pattern associated with a trusted SaaS connector. Security teams use it to tell legitimate integration traffic from abuse, especially when a valid token is used from an environment that does not match the expected vendor footprint.

What's in the full analysis

Obsidian Security's full research covers the operational detail this post intentionally leaves for the source:

• Step-by-step response sequence for revoking Salesforce OAuth grants across affected tenants
• Exact activity-log indicators used to reconstruct the June 11 to 12 query window
• Detection logic for persistence attempts such as new OAuth apps, admin additions, and webhooks
• Inventory guidance for identifying other SaaS connectors with the same CRM access pattern

👉 The full Obsidian Security post covers the attack chain, tenant impact, and response steps in detail.

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.