The new attack surface: OAuth Token Abuse
OAuth token abuse lets attackers bypass MFA and access data silently. Token theft, session hijacking, and how to strengthen your token security.
OAuth tokens have become foundational to how modern systems work together. As organizations moved to cloud architectures, widespread SaaS adoption, and remote work during the COVID-19 pandemic, OAuth provided a standardized way for applications to operate across network boundaries by enabling delegated access for users, APIs, and third-party tools.
Over time, this shifted how access works: OAuth is no longer just about user sign-ins. While identity tokens are issued to people during interactive logins and are typically short-lived and closely monitored, integration tokens are issued to applications, services, and third-party tools to enable ongoing, non-human access between systems. These integration tokens now power most SaaS-to-SaaS workflows, automations, and background processes, often persist longer, operate silently, and receive far less scrutiny.
However, this success also created deep reliance. OAuth tokens often grant broad access with little visibility. Unlike credential-based compromise, token abuse relies on malicious grants such as consent phishing with fake apps that establish OAuth connections or the hijacking of stored access and refresh tokens. In integration-heavy environments, attackers primarily replay these tokens to access APIs and services without reauthentication. Because this activity uses valid tokens, trusted applications, and legitimate authorization flows, malicious behavior blends in with normal insider and non-human activity, making detection significantly harder.
In this blog, we explore the most common types of token abuse: token theft and session hijacking, along with common attack techniques such as consent phishing that make these threats especially dangerous in modern SaaS environments.
Types of token abuse
Token Theft
Token theft occurs when attackers steal OAuth tokens after it has been legitimately issued and then use it to access APIs or services without the user having to reauthenticate. Compared to traditional attacks where usernames and passwords are targeted, the attacker targets the token itself, extracting it from browsers, devices, credential stores, and code repositories. These attacks typically occur post consent where a token is stored insecurely or exposed due to a vulnerability, allowing attackers to steal the token. The service grants access to the attacker, assuming that the user is legitimate.
Once inside, the attacker does not need to re-authenticate or complete MFA. They can then reuse the stolen token to act immediately or leverage a stolen refresh token to continuously mint new access tokens, resulting in long-term access. In many cases, an attacker stores the token while remaining silent and doing light reconnaissance to test detection capabilities.
For example, in the Salesloft-Drift breach, attackers stole OAuth tokens used by a trusted third party integration to connect to customer Salesforce environments. Rather than compromising user credentials, the attackers replayed valid OAuth tokens to authenticate directly into hundreds of Salesforce environments, bypassing MFA and quietly exfiltrating data over multiple days. Because the activity originated from a sanctioned integration using valid tokens, it blended in with normal SaaS-to-SaaS traffic and evaded traditional security controls.
This makes token theft especially dangerous as they aren’t detected by most security systems and allows the attacker to quietly access APIs, read data and take actions while appearing to be a legitimate user.
Token Session Hijacking
OAuth session hijacking involves the takeover of an active session by intercepting or gaining control of a token while being actively used. Unlike token theft which targets tokens after they are stored, hijacking occurs during a live session through methods such as adversary-in-the-middle, session fixation and stolen cookie sessions. In post user authentication, an attacker intercepts the session token and reuses it immediately, acting like an active user where the original user may be logged out or experience session anomalies.
One of the most common and effective forms of token hijacking is consent phishing where an attacker tricks users into authorizing a malicious OAuth application. The attack typically begins with a phishing email or internal integration that appears trustworthy. When the user clicks the link, they are redirected to a legitimate OAuth consent screen, which lowers suspicion and increases the likelihood of approval. Once consent is granted, the OAuth provider issues access and often refresh tokens directly to the attacker’s application, granting it sanctioned, non-human access to APIs and data.
This technique was widely used in a 2022 campaign targeting Microsoft customers, where attackers impersonated legitimate partners to enroll in the Microsoft Cloud Partner Program and create OAuth apps that appeared trusted. Victims who approved these apps unknowingly granted attackers persistent access, which was then used to exfiltrate email data, without any passwords being stolen.
What makes consent phishing especially dangerous is that the access is legitimate by design. Once a user approves the application, the identity provider itself issues valid OAuth tokens directly to the attacker’s app. Because access is tied to the authorized application rather than a user’s password, the compromise typically avoids traditional login detections and MFA enforcement. If refresh tokens are granted, attackers can continuously mint new access tokens, enabling long-term persistence. This activity often blends seamlessly into normal SaaS-to-SaaS integration traffic, making it extremely difficult to detect.
The core challenge is that most security detection models are built to identify human threats such as suspicious logins or MFA bypass attempts, not non-human identities operating through trusted integrations. In effect, attackers aren’t breaking in, they’re logging in as a trusted application, and most security tools aren’t designed to question that trust.
To prevent this, service providers must monitor for anomalous token usage and take preventive measures such as enforcing short token lifetimes, using refresh token rotation or restricting token usage with least privilege.
Summary of OAuth attack types
| Token theft | Token hijacking | |
|---|---|---|
| Definition | Stealing OAuth tokens after they have been legitimately issued and reusing them to access APIs without reauthentication | Taking over an active session or abusing OAuth consent to obtain valid tokens that grant ongoing access |
| Token state | Stolen token may be active or unused | Token is actively in use during a valid session |
| Typical attack vector | Malware, phishing, compromised storage, browser extensions | Man-in-the-middle (MITM), session fixation, network sniffing |
| Impact | Unauthorized and silent access to data & APIs, limited to token’s scope and lifespan | Grants persistent, application-level access that bypasses MFA, enabling long-term data exfiltration, cross-SaaS lateral movement, and supply chain compromise |
How to secure your OAuth tokens with Obsidian
- Eliminate manual discovery of integrations, OAuths, APIs: Obsidian provides a unified, always-up-to-date inventory of every SaaS integration across your core applications like Salesforce, Microsoft 365, and Google Workspace. Security teams can easily see OAuth apps, API keys, service accounts, and shadow integrations in one place, including who authorized them, what permissions they hold, and what data they can access
- Stop OAuth abuse and supply chain compromises: Detects token abuse, malicious OAuth grants, and third-party supply chain threats early using behavioral analytics and rich context from the Obsidian Knowledge Graph. By identifying suspicious integration activity early, organizations can disrupt attacks before they cascade across downstream applications.
- Reduce mean time to investigation and reduce blast radius: One-click impact analysis to determine if your organization is affected in industry-wide breaches, tokens involved, data accesses and guides security teams on remediation steps
When the token belongs to an agent
Token abuse changes shape when the identity behind the token is an AI agent rather than a person. A stolen human session is bounded by what that person does and when they work. An agent token is used continuously, at machine speed, against systems the agent was wired into months earlier, and its normal behavior already looks like automation.
That removes most of the signals detection relies on. What is left is context: which applications the token can reach, what it inherited there, whether the behavior matches the agent baseline, and whether the combination of access and data sensitivity was ever approved. This is the same question an anatomy of a SaaS supply-chain attack turns on, one stage earlier.
Containment when the stolen token belongs to a vendor or an agent
The Salesloft Drift pattern above is now the shape of most SaaS supply-chain breaches, and frontier AI models are shortening the path to it. An attacker who can use a capable model to find and exploit a weakness in a SaaS vendor faster than before ends up holding the same thing: valid integration tokens into every customer tenant that trusted that vendor. Nothing in your environment was breached. Something you authorized was.
That produces two attack paths worth planning for separately.
Vendor token theft. A vendor you integrated is compromised, and the tokens it held for your tenant are replayed from infrastructure you have never seen. The vendor's disclosure, when it comes, arrives days after the first replay. Your first question is not whether you were affected. It is which tokens that vendor held, what each one could reach, and whether any of them were used in a way the vendor never used them before.
Agent and automation token theft. The token belongs to an AI agent, a workflow automation, or a service account rather than to a vendor product. Its normal behavior already looks like a machine: continuous, off-hours, high volume. A stolen copy looks the same at the API layer. The difference shows up in what the token touches and from where, not in whether it is active.
Containment follows the same four moves in either case, and the order matters because the first one gates the other three.
- Know which tokens exist and what each one reaches. Not the vendor list, the grant list: OAuth apps, API keys, service accounts, and agent connections, each resolved to the applications and data it can actually touch. This is the inventory most teams discover they do not have on the day of a disclosure. The OAuth grants that survive offboarding are usually in it.
- Rank by reach, not by vendor name. A compromised vendor with read scope on a calendar is a different incident from one with org-wide write access to your CRM. Blast radius is the sort key, and what blast radius means in SaaS covers how to measure it.
- Revoke, then verify the revocation held. Rotating passwords does nothing here, because the token was never tied to the password. Revoke the grant at the identity provider and in the application, then confirm the refresh token can no longer mint a new access token. How long revocation actually takes is the honest benchmark for this step.
- Read what the token did before you found it. The activity happened under a valid identity, so it sits in the application audit logs filed as normal integration traffic. Pull it by token, not by user.
The full chain from vendor compromise to downstream data access is in the anatomy of a SaaS supply-chain attack. The product side of containing it is on the SaaS supply chain security page, and how Obsidian is preparing customers for frontier-AI supply chain threats covers the Mythos-era framing in detail.
