Salesforce OAuth token theft shows the cost of over-scoped integrations

At a glance

What this is: This is SlashID’s analysis of how stolen OAuth tokens from a trusted Salesforce integration enabled large-scale data harvesting, secret mining, and downstream pivoting into connected systems.

Why it matters: It matters because IAM teams now have to govern third-party OAuth scope, token lifetime, and integration offboarding as part of the identity perimeter, not as an application afterthought.

Context

OAuth trust relationships can become a hidden attack surface when third-party integrations are granted broader access than the business use case justifies. In this campaign, the issue was not password theft or interactive login abuse, but valid delegated access that let attackers operate inside Salesforce as if they were the integration itself.

The identity governance problem is over-scoped integration design: long-lived tokens, wide object access, and poor visibility into what connected apps can read, query, and export. Once those permissions exist, the compromise of one upstream app can expose customer data, embedded secrets, and adjacent SaaS accounts without triggering the controls teams usually rely on for human logins.

Key questions

Q: What breaks when SaaS integrations are granted broad OAuth scopes and shared profiles?

A: Broad OAuth scopes and shared integration profiles turn a single compromise into multi-application access. They remove the boundary between one app and the rest of the environment, so attackers can reuse delegated trust, query data they should not see, and pivot into other systems without needing fresh authentication.

Q: Why do stolen tokens create more risk than a one-time login compromise?

A: Stolen tokens often bypass the normal interactive login flow, so they can be reused silently until expiration or revocation. In many environments they also carry enough privilege to access shared files, messages, or admin functions. That turns an endpoint infection into an identity compromise, especially when tokens are not device-bound or tightly monitored.

Q: What are the signs that a Salesforce OAuth integration has been abused?

A: Common warning signs include unfamiliar connected apps, dormant apps with broad permissions, unexpected scope elevation, unusually large API exports, login attempts from odd geographies or times, and package installations that bypass security review. Large Bulk API jobs, report generation by unexpected users, and TOR-linked or off-hours activity are especially strong indicators that an integration may be compromised.

Q: How should teams govern third-party SaaS integrations after a token compromise?

A: Treat the integration like a privileged identity, not a convenience feature. Revalidate scope, owner, downstream dependencies, and token lifetime, then remove any connector that can reach unrelated business systems without a clear, current need.

Technical breakdown

How stolen OAuth tokens bypass normal login controls

OAuth tokens let a third-party application act on behalf of a tenant without re-authenticating the user for each action. In this case, the stolen token was already authorised, so the attacker did not need phishing, password capture, or MFA interception to reach Salesforce APIs. That matters because the trust decision had already been made upstream when the integration was granted its scopes. For IAM teams, the security boundary shifts from sign-in events to delegated access rights, token lifetime, and revocation hygiene.

Practical implication: monitor delegated access as a privileged channel, not as ordinary app authentication.

Why over-scoped Salesforce integrations create a secret graveyard

When integrations can read broad records such as Cases, Accounts, Opportunities, and Users, they also inherit everything people paste into those records. That often includes API keys, cloud tokens, URLs, and troubleshooting artefacts that were never intended to become machine-readable security assets. The result is a secret graveyard inside SaaS data stores. Attackers do not need to break Salesforce first if they can simply query the records that already contain the credentials needed for the next pivot.

Practical implication: treat application notes, case fields, and exported objects as potential credential reservoirs.

How token abuse turns SaaS access into cross-platform movement

A stolen OAuth token is rarely the end state. Once attackers can query data, they can mine embedded secrets and use those credentials to reach cloud storage, data warehouses, or other SaaS tenants. In this campaign, the pivot extended from Salesforce into other connected services, which is why the blast radius exceeded a single application. The architectural lesson is that a token with broad SaaS scope can become a bridge into an entire business ecosystem when integration governance is weak.

Practical implication: inventory downstream SaaS-to-SaaS dependencies and remove unnecessary cross-app trust.

Threat narrative

Attacker objective: The objective was to extract business data and reusable secrets from Salesforce and then convert that access into broader SaaS and cloud compromise.

1. Entry occurred when attackers obtained valid OAuth tokens tied to a trusted third-party integration, giving them authorised access without exploiting Salesforce directly.
2. Escalation happened as they used those tokens to enumerate objects, run bulk SOQL queries, and harvest embedded secrets from records and exports.
3. Impact followed when the stolen secrets and connected-access paths let the attackers pivot into additional systems, expanding the compromise beyond Salesforce.

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.
• Snowflake breach: Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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

NHI Mgmt Group analysis

Over-scoped OAuth trust is now a primary identity risk, not a secondary app issue. This breach worked because delegated access had been granted more broadly than the business task required, then left live long enough to be abused. The practical conclusion is that identity governance has to follow integration scope, not just user access.

OAuth tokens function like privileged machine credentials once they are accepted by downstream systems. The article shows that a valid token bypassed the normal control stack that teams often depend on for human identities. That makes token lifecycle, scope review, and offboarding central governance tasks for SaaS ecosystems.

Secret mining from business records is a governance failure, not just a data-exposure event. Salesforce became a secret reservoir because operational data contained credentials, URLs, and access artefacts that attackers could repurpose immediately. Practitioners should treat record content as part of the credential estate when integrations have read access at scale.

Cross-platform blast radius is the real measure of integration risk. The compromise did not stay inside one app because OAuth trust relationships connected Salesforce to email, workspace, cloud, and analytics tools. That means integration reviews must assess downstream dependency chains, not only the initial connector.

Access review models designed for human accounts undercount delegated SaaS risk. They assume a clear owner, a visible login, and a stable permission set. In delegated app access, the real control question is whether the integration still needs every scope it was originally granted. Practitioners should reframe recertification around app-to-app authority.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.

What this signals

Identity governance has to move from user-centric controls to connector-centric controls. The core failure mode here is not a bad password or a missed MFA event. It is delegated authority that outlived the business need and gave attackers a legitimate path through the environment.

Integration blast radius is the right metric for SaaS risk. A connector that can read core objects, expose embedded secrets, and reach other applications is already acting like a privileged identity. Programmes that do not inventory those cross-app dependencies will keep underestimating exposure.

Secret sprawl inside business applications is now part of the credential estate. When customer records and support cases contain keys or tokens, access governance and data governance converge. The practical response is to review where machine credentials are stored, not only where they are generated.

For practitioners

• Tighten OAuth scope baselines Review every third-party integration against the minimum object, field, and API permissions required for its business function. Remove read access to records that can contain embedded credentials unless the integration absolutely needs it.
• Shorten token lifetimes and revoke stale grants Set explicit expiry and rotation expectations for OAuth tokens, then remove integrations that have not been actively validated by the business owner. Long-lived delegated access should be treated as privileged access.
• Scan business records for embedded secrets Search Salesforce notes, cases, and exported objects for API keys, cloud tokens, and other machine credentials that may be exposed to integration users. Treat findings as credential incidents, not just data-quality issues.
• Monitor delegated API activity for bulk access patterns Alert on unusual SOQL volume, broad object enumeration, atypical user agents, and access from infrastructure that does not match the normal integration footprint. Use those signals to distinguish routine sync from exfiltration.
• Map downstream SaaS trust chains Document which apps can reach Google Workspace, Slack, AWS, Azure, and analytics tools through shared OAuth relationships. If a connector can pivot into other systems, its governance scope must include those dependencies.

Key takeaways

• Over-scoped OAuth integrations can turn a trusted app into a privileged identity path that bypasses normal login-based detection.
• The campaign showed how SaaS records can become a reservoir for API keys, cloud tokens, and other reusable secrets.
• Practical defence starts with scope reduction, token lifecycle control, and continuous review of downstream SaaS trust chains.

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.
• Over-Scoped Integration: An over-scoped integration is a connected application that has been granted more data, object, or API access than its business purpose requires. In identity governance terms, it creates unnecessary blast radius because any compromise of the connector inherits the excess privilege.
• Credential Graveyard: A credential graveyard is the accumulation of expired, unused, or orphaned secrets that still authenticate in production. These stale service accounts, API keys, and certificates create hidden access paths that survive long after their original purpose has ended.
• 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.

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.