OAuth Token Abuse in Supply-Chain Attacks

OAuth token abuse works because a token skips authentication entirely. Once a user or admin approves an app, the SaaS platform issues a token that stands in for that identity on every future API call. There is no password check, no MFA prompt, no geolocation test, no new-device warning. The token is the identity, and whoever holds it is trusted.

This is the mechanics of machine insider risk. Human identity controls assume a person logs in from somewhere, on something, at some time you can reason about. A machine identity presents as trusted API traffic that already cleared authentication, sometimes months earlier. The controls that watch your front door never see the token walk in the side.

What counts as OAuth token abuse

OAuth token abuse is the use of a stolen or over-scoped access token, refresh token, or client secret to read, exfiltrate, or change SaaS data outside the intent of the original grant. The abuser might be an external attacker who stole the credential, a compromised third-party vendor whose tokens were harvested, or an AI agent acting with more effective authority than the person who invoked it should ever have.

Three properties make tokens worth stealing:

• Portability. A token pulled from a laptop, a CI pipeline, or a vendor's cloud works from anywhere.
• Invisibility. The API call looks identical whether the caller is legitimate or hostile.
• Scope inheritance. The token carries every permission its user or app was granted, which is usually far more than the task in front of it needs.

How attackers get the tokens

Tokens leak from predictable places, and attackers go after the weakest storage location rather than the SaaS platform itself. Common sources include compromised third-party vendors that store customer tokens, client secrets left in public repositories and CI/CD logs, malicious or typosquatted OAuth apps that trick users into consenting, phishing pages that relay a real consent screen and capture the returned code, and cached refresh tokens sitting in developer tooling on a stolen laptop.

Refresh tokens are where the real dwell time lives. An access token might last an hour, but the refresh token behind it can silently issue new access tokens for 30, 60, or 90 days, and in some configurations far longer. That window is the part attackers actually care about, because it turns a single theft into standing access.

Setting token lifetimes that limit blast radius

Short-lived access tokens paired with tightly scoped refresh tokens shrink the blast radius of any single theft. Keep access tokens short when the data is sensitive or the theft risk is high, and reach for longer-lived refresh tokens only when you control both ends of the integration and can watch its behavior continuously.

The rule of thumb: if you cannot detect abuse inside a token's lifetime, that token is too long-lived. A 90-day refresh token with no monitoring is a 90-day head start you are handing to whoever steals it.

Supply-chain attacks use one stolen token to reach many victims. The attacker never has to breach the customer directly. They breach the vendor that already sits inside the customer's SaaS stack, holding tokens for everyone who connected it.

One token, many tenants

The pattern is consistent. A third-party app is granted OAuth access to a core SaaS platform by every one of its customers. The vendor stores those customer tokens in its own environment. When the vendor is breached, the attacker walks out with tokens for hundreds or thousands of downstream tenants. Each token gets used from the attacker's infrastructure, but on the wire it reads as ordinary vendor API traffic.

Documented examples

• Salesloft Drift and Salesforce (2025). Actors tracked as UNC6395 extracted OAuth tokens from a widely connected chat integration and pivoted into roughly 700 downstream Salesforce tenants. The campaign was reported by Google's threat intelligence team and confirmed by Salesforce.
• A nation-state OAuth mailbox campaign against a major cloud provider (2024). Attackers abused an over-privileged OAuth application to read executive mailboxes, a case the provider disclosed publicly.
• Stolen CI and platform OAuth tokens against source repositories (2022). Tokens issued to build and deployment vendors were reused to download private repositories from dozens of organizations, as disclosed by the affected code host.

Across all of them the common denominator is not the platform that got raided. It is the third-party integration that held the tokens.

Every OAuth grant is a non-human identity, and non-human identities already outnumber human ones in most enterprises by a wide margin. Every new AI agent, workflow automation, and third-party integration adds more. If your identity program only governs the humans, most of your identities are ungoverned by definition, and the token abuse path runs straight through the gap.

Which scopes to refuse by default

The scopes most often abused in supply-chain breaches share a shape: tenant-wide read access to unstructured data. Start by refusing them unless a documented business case survives review.

• Deny "read all mail," "read all files," and "read all messages" scopes without a reviewed justification.
• Require admin consent for any scope that touches cross-user data.
• Block "offline_access" for apps that have no genuine need for refresh tokens.
• Restrict client-credential grants to a named service account with a rotation schedule.
• Refuse consent to apps from unverified publishers.

If a marketing or productivity tool asks for admin-level scopes, treat that as a red flag, not a feature.

Governing OAuth apps as identities

Governance here looks like identity lifecycle, not a one-time config check. Enforce admin-consent workflows so a single user cannot grant tenant-wide scopes alone. Keep an allow-list of approved publishers. Review third-party integrations quarterly rather than annually. Rotate client secrets on a schedule and again after any vendor security incident. And inventory every token as a non-human identity with an owner, a purpose, a scope, and an expiration, so no grant is anonymous.

Configuration is not reality. Two tokens carrying identical scope strings can have wildly different effective access once you resolve the real entitlements of the user or service principal behind each one. The scope tells you what the app asked for. It does not tell you what the token can actually reach.

That gap is where supply-chain attacks do their damage. A token's real reach depends on the invoking user's role, group memberships, and record-level permissions inside the app; on any impersonation, delegation, or maker-mode setup where the token runs as its creator; on downstream connected apps it can chain into through federation; and on data classifications the scope string never describes. A CRM read token bound to a sales admin's account has a very different blast radius than the same scope bound to a single sales rep.

This is the correlation that matters, and it is where Obsidian focuses. Instead of reading a vendor's theoretical config page, tie each agent or token to its effective access inside the third-party app: which service account it runs as, which tables and objects it can reach, and which actions it actually took. Runtime truth about what a token did, resolved against the entitlements behind it, is the only thing that separates a harmless integration from a machine insider with tenant-wide reach.

Who is most exposed

Organizations running heavy SaaS stacks with many third-party integrations carry the most risk. Tenants with dozens of connected apps across their core CRM, productivity, and collaboration platforms sit at the top. Teams deploying AI agents add another layer, because those agents hold long-lived tokens with broad scopes and often run as their creator, so every invoker inherits that reach.

Detection depends on runtime behavior, not policy review. At the auth layer the token looks legitimate, because it is legitimate. The abuse only shows up in what the token does once it is in someone else's hands.

What abuse looks like at runtime

• API calls from IP addresses or networks the token has never used before
• Unusual data volumes, especially bulk exports or wildcard queries
• Access outside business hours for tokens tied to interactive users
• Requests to endpoints the app has never called before
• New refresh-token issuance from unexpected regions

Warning signs from the environment reinforce the picture: a vendor discloses a breach and you had their app installed, users report consent screens they never initiated, audit logs show admin-consent grants nobody approved, or a low-traffic integration suddenly spikes in API volume.

Token theft is not session hijacking

Session hijacking steals a browser cookie tied to one user and usually dies on logout or timeout. OAuth token theft steals a credential minted for programmatic API access, often with long-lived refresh capability and no dependence on any browser session at all. Session hijacking is a user problem. OAuth token abuse is a machine identity problem, and it outlives the session that created it.

Revocation is containment, not remediation

You can revoke a token, but revocation only stops future use. It does not roll back data already exfiltrated, records already changed, or webhooks and forwarding rules the attacker already created. After you revoke, rotate the affected app's client secrets, force reconsent from a clean state, audit every call the token made during its lifetime, hunt for attacker-planted persistence, and notify downstream systems and regulators as your obligations require.

That audit step is the hard one, and it is where most teams stall. Native SaaS logs are fragmented and often miss cross-app activity, so the honest answer to "what did that token touch" is frequently a shrug. Obsidian's role is to close that gap on the discover and govern side: map every OAuth grant, agent credential, and integration into one control plane, correlate each token's theoretical scope with its effective access inside each app, and surface toxic combinations such as a vendor token with tenant-wide read and no owner. When a Salesloft-style incident hits, the question moves from "did we have that app installed" to "exactly which records did that token touch, and when." That is evidence that generates itself instead of a fire drill.

A note on runtime enforcement, because the market blurs it. Autonomous, inline blocking of a live agent action exists today only for Claude and Microsoft Copilot, and Obsidian is not an inline gateway even there. It works as an Intel Inside decision engine that the platform consults. For every other platform, including Agentforce, Snowflake Cortex, ServiceNow Now Assist, Moveworks, Bedrock, and Vertex, treat the capability as discovery and governance today, with runtime enforcement on the roadmap rather than in production. Detection and revocation, the workflow this section describes, apply broadly regardless.