Topic starter
15/08/2026 6:07 pm
TL;DR: Attackers stole Klue’s OAuth tokens and used the trusted integration to bulk-extract Salesforce CRM data across multiple enterprise environments, exposing a SaaS supply chain access path that bypassed passwords and MFA, according to Obsidian Security. The incident shows why integration inventory, token revocation, and blast-radius mapping are now core identity controls, not afterthoughts.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “The Trusted Integration That Wasn't: Inside the Klue SaaS Supply Chain Attack on Salesforce”.
Key questions
Q: What breaks when a third-party SaaS integration loses trust but its token stays valid?
A: The control that breaks is the assumption that revoking the application relationship automatically removes access.
Q: Why do OAuth tokens and service accounts increase SaaS supply chain risk?
A: They create persistent, non-human access paths that do not depend on repeated MFA or user interaction.
Q: How should teams detect abuse of a legitimate SaaS integration?
A: By combining token-aware telemetry with behaviour baselines for the integration account.
Practitioner guidance
- Revoke compromised OAuth grants immediately Remove the Klue token and any remaining grants from Salesforce, then verify that no equivalent delegated access still exists in connected tenants.
- Inventory every connected SaaS integration List all OAuth apps connected to Salesforce, record the scopes each one holds, and assign an owner for each integration account.
- Map the CRM blast radius by object and tenant Identify which Salesforce objects the integration could read across each tenant so you know which records were exposed if the token was abused.
Bottom line: A stolen OAuth token can convert a routine SaaS integration into a high-trust access path that bypasses passwords and MFA.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 6:16 pm
OAuth trust debt is now a first-class identity risk: The central problem is not that integrations exist, but that many SaaS programmes treat delegated access as a setup event rather than a living control surface. Once a token is granted, the trust relationship can persist long after the original review context has changed. Practitioners should read this as a signal that integration trust now needs the same governance discipline applied to privileged accounts.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should IAM teams prioritise after a third-party OAuth breach?
A: First, revoke or re-issue active tokens tied to the compromised integration, then review where those tokens had access and whether the same scopes exist elsewhere. After that, tighten consent, logging and secret-detection controls so one SaaS compromise cannot expose credentials stored in business records.
👉 Read our full editorial: Klue’s OAuth token theft exposes SaaS supply chain access risk