Table of Contents
OAuth brings tremendous utility when implemented correctly. However, misconfigurations can affect even the most sophisticated platforms and services. Parameter manipulation, supply chain exploits, and gaps in identity handling all highlight how challenging OAuth can be to implement securely.
And because OAuth supports billions of daily logins across consumer and business applications, even small misconfigurations can create outsized security risks.
In this article, we’re taking a critical look at the ways OAuth can go wrong and how you can avoid them. Each case presented here was responsibly disclosed and has been patched or remains under investigation. While immediate risks from most of these exploits have been addressed, they provide valuable lessons about OAuth security, all of which are relevant today.
In what follows, we’ll cover:
How OAuth vulnerabilities occur
Examples of high-profile OAuth failures
Common OAuth misconfigurations developers encounter
How to fix OAuth vulnerabilities (and prevent new ones)
Understanding OAuth vulnerabilities and misconfigurations
OAuth uses temporary tokens instead of passwords to authorize access across platforms and services. While the protocol itself is secure, implementation errors create exploitable vulnerabilities. Many of these fall under broken authentication, a critical security risk that enables unauthorized access.
Most OAuth vulnerabilities stem from these implementation errors rather than flaws in OAuth's architecture. OAuth commonly uses JSON Web Tokens (JWTs) for token format. While JWTs sign tokens to verify integrity, they don't encrypt the payload by default, meaning sensitive data should never be stored directly in JWT claims. This makes proper token handling and scope management critical for OAuth security.
As OAuth integrates with more third-party providers, each connection introduces potential points of failure, from redirect URI validation to token storage across different platforms. A single misconfiguration in any integration can compromise the entire authentication flow.
OAuth exploits typically target gaps in three areas: redirect URI validation, token scope management, and identity verification. Attackers exploit these weaknesses to intercept tokens, escalate privileges, or impersonate legitimate users. The vulnerabilities detailed below demonstrate how these implementation mistakes create real security incidents.
While high-profile exploits get the most attention, most OAuth failures stem from ordinary implementation mistakes: improper redirect validation, overly permissive token scopes, and insecure token storage. These misconfigurations often exist for months before attackers discover them—making proactive security reviews essential.
Common OAuth misconfigurations developers encounter
Most OAuth vulnerabilities don't make headlines. They're subtle implementation errors that create exploitable conditions long before attackers find them.
Below are several of the most common classes of OAuth misconfigurations and why they matter.
Improper redirect URI validation
Failing to strictly validate redirect URIs (especially allowing wildcard paths or partially matched domains) creates classic open redirect scenarios that allow attackers to intercept tokens. Threat actors use these gaps to intercept authorization codes or tokens by routing users through attacker-controlled URLs.
Excessively broad token scopes
Using least-privilege scopes limits what an attacker can do even if a token leaks. Tokens that grant more permissions than necessary widen the blast radius of any compromise. If a token intended for one narrow action can instead read repositories, modify data, or access multiple services, any attacker who obtains it gains dangerous levels of access.
Insecure token storage
A compromised device, browser extension, or debugging tool can access these values and immediately reuse them. Storing tokens in easily accessible locations (such as localStorage, logs, or unencrypted server files) creates another path for compromise. OAuth depends on secure token handling, and any leakage (even through developer tooling) can undermine the entire flow.
Relying on mutable identifiers for authorization
Many apps mistakenly use email addresses or domains as the unique identifier in OAuth flows. Because these values can be changed, recycled, or reassigned, they’re not reliable for authorization decisions. As several real-world exploits have shown, mutable identifiers can lead to account takeover when domains expire or email claims are spoofed.
Weak validation across OAuth providers
Each OAuth provider implements claims and identifiers slightly differently. Treating providers as interchangeable without validating their specific security guarantees can introduce inconsistencies, especially when services fall back to non-immutable claims. These inconsistencies often become the root cause of subtle account-linking or impersonation issues.
High-profile OAuth vulnerabilities
Aside from underlying vulnerabilities affecting all OAuth implementations, several high-impact cases in recent years illustrate how misconfigurations turn into real security incidents. These examples highlight the same patterns developers encounter during everyday implementation, just at a much larger scale.
Below are five widely discussed OAuth vulnerabilities and what they teach us about secure implementation.
Token theft that impacted GitHub, Heroku, and Travis CI
An OAuth redirect manipulation found on Booking.com
A proxy weakness that targeted the Expo platform
Domain takeover exploits via “login with Google”
OAuth misconfiguration flaws in Microsoft Azure
First, we’ll walk through what each vulnerability means. Then, we’ll unpack practical advice for how to deal with these and any related OAuth vulnerabilities that emerge.
GitHub, Heroku, and Travis CI OAuth token theft
One of the clearest examples of OAuth going wrong occurred when token handling practices broke down across trusted integrations. This exploit involves reusing stolen tokens from trusted integrations to scan, select, and steal from highly targeted GitHub repositories. Unlike most of the risks we’ll discuss (which were disclosed by security researchers), this attack led to real damage affecting multiple entities.
Here’s what happened: instead of trying to breach GitHub accounts directly, attackers went after OAuth tokens held by trusted integrators Heroku and Travis CI. These tokens enable workflows, like deploying code living on GitHub to apps running on Heroku. The attacker stole the tokens and used them to bypass auth on GitHub for the associated accounts, with preferred targets.
The attackers were particularly interested in Node Package Manager (npm), which GitHub acquired in 2020. After accessing private repositories, attackers found Amazon Web Services (AWS) credentials that gave them access to npm’s web infrastructure. An unknown number of organizations had repositories cloned, and the number of affected accounts is still confidential.
What this teaches us: Token security extends beyond your own implementation.
Key prevention steps
Audit OAuth integrations regularly for excessive scopes
Use least-privilege scopes for all tokens
Implement secure token rotation
Build capabilities to detect and revoke compromised tokens
Booking.com OAuth redirect manipulation
Another major incident demonstrated how redirect URI validation (one of OAuth’s simplest requirements) can unravel when not enforced strictly. On the level of vulnerability rather than attack, in 2022, researchers at Salt Labs uncovered flaws in Booking.com’s OAuth implementation around how the platform handled redirect URIs.
In a properly configured OAuth system, the redirect_uri parameter tells the OAuth provider in a social login scenario exactly where to send users after they’ve authenticated. This URI should be strictly validated to prevent malicious redirects, but Booking.com’s implementation allowed threat actors to send users to an attacker-controlled domain. This attack vector is known as an “open redirect,” and it’s often exploited to capture tokens and bypass authentication.
The Booking.com vulnerability worked through a chain of interconnected failures. While Facebook, as the OAuth provider, properly validated that the redirect URIs belonged to Booking.com’s domain, the implementation didn’t enforce exact path matching. An attacker could send a modified URL to a victim, which would route them through a series of redirects that ultimately expose auth secrets. Threat actors could potentially capture codes and reuse them by “signing in” with Facebook, replacing their code with the one stolen from the victim.
Salt Labs discovered that the vulnerability extended to a sister company, Kayak.com, effectively doubling the attack surface and potential impact. Meanwhile, researchers quickly realized that the exploit worked regardless of which OAuth provider the user chose (Google, Facebook, etc.).
The upshot is that the underlying implementation flaw was the same across these variables, placing responsibility for mitigation solely on Booking.com. Fortunately, the travel company resolved the security gap, and Salt Labs confirmed the exploit was no longer effective.
What this teaches us: Redirect URI validation is one of OAuth's simplest requirements, yet frequently misconfigured.
Key prevention steps
Validate redirects against strict, path-specific whitelists
Never allow open redirects in OAuth flows
Test redirect behavior with all OAuth providers
Expo proxy vulnerability
A similar pattern appeared in Expo’s OAuth proxy service, where improper handling of return URLs created a new path for token exposure.
In 2023, Salt Labs uncovered another critical flaw in a popular service’s OAuth implementation. This time, researchers examined the authentication proxy service for the open-source dev platform Expo. This issue stemmed from Expo’s proxy service and its handling of return URLs, similar to redirect manipulation in execution but coming from a different attack vector.
Researchers found they could manipulate the returnURL parameter to send OAuth tokens to attacker-controlled domains, much like the redirect exploit used in the Booking.com example.
In practice, attackers could create a malicious URL that, when clicked, would launch a legitimate OAuth flow through Expo’s proxy. When auth was done, instead of returning to the legitimate app, the OAuth tokens would be sent to an attacker-controlled domain. With these tokens, a threat actor could take over any user account on an app using Expo’s OAuth implementation.
The Expo incident highlights the risks of relying on third-party OAuth implementations without fully vetting their security practices. While Expo quickly patched the issue and deprecated the problematic proxy service, the case shows how a single security oversight in a widely used platform can create systemic risks across connected apps and why vigilance is imperative.
What this teaches us: Third-party OAuth implementations introduce systemic risks. A single security oversight in a widely used platform like Expo can compromise hundreds of connected apps.
Key prevention steps
Thoroughly vet third-party OAuth implementations before integration
Validate all parameters in OAuth flows, regardless of use case
Monitor token usage patterns for anomalies
Maintain ability to quickly deprecate or update compromised auth components
Google OAuth domain takeover exploit
OAuth implementations can also fail when they rely on identifiers that change over time. Google's domain takeover exposure highlights this flaw.
In September 2024, Truffle Security discovered an OAuth vulnerability in Google’s “Sign in with Google” feature. It allows attackers to take over accounts by exploiting how Google’s OAuth handles domain ownership changes. While Google’s security team initially labeled the issue as “fraud and abuse" rather than a bug, they’ve since reopened the ticket for investigation.
The vulnerability plays off an all-too common scenario: startup company failure.
When a startup goes under, its domain will eventually expire. It then becomes available for purchase, meaning anyone can buy it, recreate email accounts matching former employees, and impersonate them via social login. Google’s OAuth implementation allows these “reanimated” accounts to access any service where employees previously used “Sign in with Google.” This includes apps like ChatGPT and Slack, and even HR systems with sensitive personal data.
Google has responded by recommending proper domain closure procedures, which means companies that see the writing on the wall should clean up their OAuth connections. And, at the time of this blog's publication, Google is still actively investigating solutions to the exploit.
A core part of the issue is that other services rely on mutable identifiers (like email and domain) instead of immutable sub-claims. Sub-claims are intended to be unchangeable, though some security researchers have shown that Google’s can occasionally change. According to Truffle Security, Google’s sub-claims changed in about 0.04% of logins, resulting in hundreds of authentication failures per week. Due to this inconsistency, services began to depend on email addresses and domain verification.
Unfortunately, both of these identifiers are up for grabs from the open marketplace, where Truffle Security estimates more than 116,000 failed startup domains are available for purchase.
What this teaches us: Relying on mutable identifiers like email addresses and domains for authorization creates long-term vulnerabilities. When domains expire, those identifiers become available for anyone to claim and exploit.
Key prevention steps
Use immutable identifiers (the `sub` claim) instead of email addresses
Enforce additional identity verification where possible (adaptive MFA)
Understand the risks of expired or recycled domains in your user base
Implement domain closure procedures for organizations winding down
Active Directory OAuth misconfiguration
This same weakness—trusting mutable identifiers—also surfaced in Azure AD’s OAuth flow, creating the nOAuth misconfiguration.
In early 2023, Descope uncovered a critical flaw in how Microsoft Azure Active Directory (AD) handles OAuth authentication–an issue we named "nOAuth.” The misconfiguration centers on a fundamental weakness in how Azure AD handles email claims in its OAuth implementation, allowing attackers to impersonate other email addresses without proving domain ownership.
This exploit is similar mechanically to the previous Google OAuth domain hijacking example in that it abuses the email and domain parameters to impersonate an actual, legitimate user.
While the exploit was still live, anyone with an Azure AD tenant could modify email addresses to be the same as a target account, even if they didn’t control the associated domain. An attacker with a copied email address could have used "Log in with Microsoft" to gain unauthorized access across multiple services, including several authentication providers. Considering many apps use email addresses as OAuth identifiers–which, as we discussed in the Google example, is usually due to ignoring sub-claims–threat actors had access to a massive attack surface.
Here’s a visual representation of the attack flow:
Microsoft took swift action after our disclosure. The company initially recommended avoiding email claims for authorization purposes, rejecting unverified email claims for existing apps, and moving to an immutable identifier. Later, it released two claims that would explicitly identify whether an email claim came from a domain-verified email and redact the claim if needed.
What made nOAuth particularly significant was how it highlighted that organizations could be vulnerable if they trusted mutable claims like email addresses as unique identifiers. Read our complete nOAuth disclosure and Microsoft’s nOAuth statement for further context on the risk.
What this teaches us: Email claims can be spoofed when domain verification is weak. The nOAuth vulnerability showed how trusting unverified email claims creates massive attack surfaces across multiple services.
Key prevention steps
Use immutable identifiers (like the `sub` claim) instead of email addresses
Validate email ownership before merging or linking accounts
Implement proper domain verification workflows
Check whether email claims come from domain-verified sources before trusting them
How to address OAuth vulnerabilities and misconfigurations
The vulnerabilities above illustrate that OAuth is not completely risk-free, despite its being a security upgrade over more traditional authorization approaches. Each example also comes with important lessons on what developers, adopters, and others can do to keep OAuth secure.
1. Follow strict token-handling and least-privilege practices
The Heroku and Travis CI attacks show how dangerous overly broad or long-lived tokens can be. Apps looking to integrate with other services through OAuth (like GitHub in this example) should adopt token-handling best practices, including:
Establishing clear scopes that follow the principle of least privilege.
Implementing secure token rotation, server-side verification, and parameter validation.
Storing tokens securely on both the server and client sides. For guidance on safe storage patterns, see our developer guide to JWT storage.
Building capabilities to quickly detect and revoke compromised tokens.
2. Right-size scopes and token usage when integrating with platforms
Similarly, services integrating with platforms (like Heroku and Travis CI) need to:
Request only the minimum scopes needed for functionality.
Store JWT tokens securely for any server-to-server workflows.
Prepare processes to respond immediately if tokens are compromised.
3. Enforce strict redirect and return URL validation
The Booking.com case highlights how teams implementing OAuth-based auth need to:
Validate all redirects against a strict, path-specific whitelist.
Never allow open redirects in any OAuth flow.
Review how redirect behavior interacts with external OAuth providers to avoid widening the attack surface.
4. Fully vet third-party OAuth implementations
The Expo proxy vulnerability underlines how OAuth integration requires:
Thorough vetting of third-party implementations to understand their security models.
Proper validation for all parameters in OAuth flows, regardless of use case.
Token monitoring and the ability to quickly deprecate or update flawed components.
Awareness of intermediary security risks, as outlined in our breakdown of the Expo authentication proxy vulnerability.
5. Account for mutable identifiers when using Google OAuth
Developers implementing Google-based OAuth solutions need to:
Enforce additional identity verification where possible (e.g., adaptive MFA).
Avoid using mutable claims like email for authorization or verification.
Consider the risks inherent to expired or recycled domains.
6. Use immutable identifiers and domain verification with Azure AD
Developers using Azure AD in conjunction with OAuth should:
Use immutable identifiers (like the sub claim) instead of email addresses.
Validate email ownership before merging or linking accounts.
Implement proper domain verification workflows.
For detailed guidance on safely unifying identities across OAuth providers — including how to merge accounts without relying on mutable claims — see our walkthrough on securely merging OAuth identities.
Ultimately, anyone implementing, managing, or using OAuth needs to be fully aware of its possible vulnerabilities. Implementing general auth best practices is a starting point, but the best long-term security assurance comes from a dedicated auth platform.
Optimize your OAuth security
OAuth is a powerful framework, but as these cases show, even trusted implementations can go wrong in subtle and unexpected ways. The issues above stem from small gaps in validation, third-party integrations, or the use of mutable identifiers, all of which can cascade into serious vulnerabilities.
The reality is that OAuth security is difficult to get right consistently. Every new provider, redirect, or integration adds more complexity, and even minor misconfigurations can have outsized impacts.
Rather than building and maintaining every part of OAuth security yourself, many teams rely on managed OAuth authentication platforms like Descope to handle token validation, provider differences, secure storage, and identity unification. This approach helps developers stay focused on product work while ensuring OAuth flows remain resilient and up to date.
If you’re looking to strengthen your OAuth implementation, sign up for a Free Forever account with Descope and start building secure, scalable auth flows today in just a few lines of code. Have questions about OAuth? Book time with our experts.
For more authentication and security best practices, subscribe to our blog or follow us on LinkedIn.
