Klue OAuth token compromise shows third-party access risk in Salesforce

At a glance

What this is: This is a breach analysis of compromised OAuth tokens tied to a third-party integration and the limited Salesforce exposure that followed.

Why it matters: It matters because IAM and PAM teams must govern third-party access lifecycles, revocation, and monitoring as part of NHI and human identity control planes, not as an afterthought.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Commvault's analysis of the Klue OAuth token breach and Salesforce exposure

Context

OAuth-connected applications extend trust beyond the systems an organisation directly controls, which is why integration risk often becomes identity risk. In this case, a compromised third-party token opened a route into Salesforce rather than into the target company’s core infrastructure, showing how delegated access can become the weak link in enterprise security.

For IAM, NHI, and security architecture teams, the operational lesson is straightforward: the control boundary now includes every authorised integration, its token lifecycle, and the revocation process when trust changes. That is typical of modern SaaS environments, where business convenience outpaces access governance unless reviews, logging, and offboarding are continuous.

Key questions

Q: What breaks when a third-party OAuth app is compromised?

A: A compromised OAuth app inherits whatever delegated scopes users already approved, so the attacker can act through legitimate tokens instead of noisy intrusion methods. That breaks the assumption that user consent remains trustworthy after the app's security posture changes. The practical result is broader access to mail, documents, directories, and other linked systems until the grant is revoked.

Q: Why do OAuth-connected third-party apps create identity risk?

A: OAuth-connected apps extend trust beyond the organisation’s own perimeter into a vendor’s security posture. If the integrator is compromised, attackers can inherit downstream access through valid tokens without attacking the customer directly. The risk grows when grants are broad, refresh-capable, or left in place without ownership review.

Q: How do security teams know whether secrets access is too broad?

A: A secrets model is too broad when a workload can retrieve credentials outside the service’s direct runtime needs, especially across environments or business functions. The clearest signal is when one role can read many more secrets than the application actually uses. That gap shows the vault is functioning as a credential store, not a control point.

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

How compromised OAuth tokens become trusted downstream access

OAuth does not hand out a user password. It issues a delegated token that authorises a connected application to act within a defined scope, often across SaaS platforms. If that token is stolen, the attacker inherits the trust relationship rather than breaking authentication directly. The risk rises when integrations have broad scopes, long-lived tokens, or weak monitoring around token use. In practice, the attacker is not impersonating the user in the usual sense, but exploiting an authorised delegation path that downstream systems accept as legitimate.

Practical implication: Treat OAuth tokens as high-value credentials and restrict scopes to the minimum access the integration actually needs.

Why third-party integrations expand the identity attack surface

Each connected application becomes part of the organisation’s identity fabric, even when it is owned by an external vendor. That fabric includes service permissions, API trust, consent records, and the operational rules for disabling access when risk changes. The more integrations that can read or sync data into core platforms such as Salesforce, the more likely one weak link will expose multiple tenants or customers. This is why third-party access governance belongs alongside secrets management and privileged access review, not inside procurement alone.

Practical implication: Inventory every connected application, classify its access, and tie approval to periodic revalidation of scope and business need.

How containment works once a token compromise is detected

Containment for token compromise depends on speed and completeness. The first steps are revoking the token, disabling the integration, checking whether any secondary tokens or refresh credentials were issued, and validating what data the integration could reach before revocation. Because OAuth abuse often leaves little malware or endpoint evidence, investigators must rely on platform logs, consent records, and access telemetry to reconstruct what the token touched. Without those records, it is hard to prove whether exposure stayed limited or silently broadened.

Practical implication: Pre-stage an integration revocation runbook and ensure platform logs are retained long enough to support forensics.

Threat narrative

Attacker objective: The attacker sought trusted access to downstream business data by abusing valid third-party OAuth delegation.

1. Entry occurred when a threat actor compromised OAuth tokens associated with a third-party integration rather than attacking Salesforce directly.
2. Escalation came from reusing those delegated tokens to access downstream customer environments that had authorised the integration.
3. Impact was limited exposure within Salesforce data stores, demonstrating how trusted application access can be abused at scale.

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

Third-party OAuth access is now an identity governance problem, not just a vendor risk problem. The breach pattern here is about delegated trust, not perimeter failure. Once an application is authorised to sync into Salesforce, its token lifecycle, scope, monitoring, and offboarding become part of the enterprise identity control plane. Practitioners should treat connected apps as governed identities with explicit ownership and revocation criteria.

OAuth token compromise exposes a verification trust gap. Organisations often assume that authorisation at setup time remains valid throughout the integration’s life. That assumption breaks when the external service, its threat posture, or its business purpose changes. The gap is especially visible in SaaS ecosystems where consent is durable but assurance is not. Practitioners should revalidate both the business need and the trust basis for every connected app.

Standing delegated access is the real exposure window in this pattern. The attack succeeds because access exists before a security event, not because an attacker invents new privilege. That is why lifecycle discipline matters as much as detection. For identity programmes, the concept to sharpen is delegated trust persistence: a token or consent grant can remain active long after its risk profile has changed.

Security teams need to align SaaS integration governance with NHI and PAM thinking. OAuth tokens, refresh tokens, and service-to-service credentials are operationally similar to other non-human identities in that they can outlive the business context that justified them. The governance response should therefore include scoped entitlement review, monitoring for abnormal token use, and fast revocation. Practitioners should fold integrations into the same review rhythm used for privileged accounts and service credentials.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to our 2024 ESG Report: Managing Non-Human Identities.
• For a broader control baseline, see OWASP Non-Human Identity Top 10 for the governance patterns that most often fail when integrations are over-permissioned.

What this signals

Delegated trust persistence will remain a recurring control gap until organisations treat OAuth grants as lifecycle-managed identities rather than static setup artefacts. The practical signal is whether access review includes connected apps, not just users and service accounts. When token scope, ownership, and revocation are not continuously revalidated, incident response becomes the first time anyone fully understands the trust chain.

For IAM and security architects, the next maturity step is to merge SaaS integration governance with privileged access management and NHI oversight. That means mapping authorised apps to data domains, retaining token telemetry, and tying offboarding to a real revocation workflow rather than a procurement record. The organisations that do this will reduce the blast radius of the next third-party compromise.

The broader programme implication is that third-party access can no longer be treated as a vendor-only control domain. If a connected app can reach core business data, it belongs in identity governance, threat monitoring, and resilience planning. Practitioners should use the same discipline they apply to other non-human identities: ownership, scope, telemetry, and rapid removal when trust changes.

For practitioners

• Inventory all authorised SaaS integrations Create a complete list of connected applications, the data they can reach, and the business owner accountable for each integration. Prioritise any app with Salesforce, CRM, or customer-data access because those paths often hold broad delegated permissions.
• Revalidate OAuth scopes and consent records Review whether each integration still needs its current scopes, refresh tokens, and data sync permissions. Remove stale access, tighten scopes where possible, and require documented approval before any expansion of read or write access.
• Add token revocation and containment runbooks Define the exact steps for disabling an integration, revoking associated credentials, and confirming whether secondary credentials exist. Include log sources, owner contacts, and decision points for disconnecting an app that no longer meets security standards.
• Monitor for abnormal third-party token usage Use platform telemetry to detect unusual token timing, source, volume, or API call patterns. Focus on refresh token reuse, off-hours access, and integrations that access data outside their normal business function.

Key takeaways

• Compromised OAuth tokens turn authorised integrations into attacker-controlled access paths, which is why third-party access now sits inside identity governance.
• The evidence across NHI research shows that visibility gaps and breach frequency remain high, especially where organisations cannot track connected applications well enough to revoke them quickly.
• The limiting control is lifecycle discipline for integrations: scoped permissions, continuous review, telemetry, and fast revocation when trust changes.

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.
• Third-Party OAuth Integration: A third-party OAuth integration is an external application that receives delegated access to a SaaS environment through user or admin consent. It expands the attack surface because the integration can become a trusted access path, so security teams must classify and monitor it like any other privileged NHI.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
• Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.

What's in the full analysis

Commvault's full article covers the operational detail this post intentionally leaves for the source:

• The incident response sequence used to disable the Klue integration and assess the scope of access.
• The specific categories of Salesforce data reviewed during the investigation and the limits of confirmed impact.
• The transparency and customer-guidance language the vendor used in its Trust Center updates.
• The governance steps Commvault describes for reviewing connected applications and reducing exposure over time.

👉 Commvault's full post covers the incident response, containment actions, and investigation scope.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build the control and lifecycle discipline needed across modern identity programmes.