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 issues 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
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
