Table of Contents
OAuth vulnerabilities and misconfigurations can affect even the most sophisticated platforms and services. From subtle parameter manipulation to supply chain exploits, these security misfires have repeatedly shown how complex OAuth can be to implement correctly. 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 either been patched or remains under active investigation. While the immediate risks from most of these exploits have been addressed, they provide valuable lessons about OAuth security, all which are still relevant today.
In each example, we'll look at what went wrong, the potential impact (or damages, if an attack occurred), and how to prevent similar issues in your own projects.
You can get a quick refresher on OAuth fundamentals from our comprehensive guide. In a nutshell, OAuth is an authorization framework that uses temporary tokens instead of actual credentials to grant access to cross-platform resources. It powers many common web interactions, with social login (e.g., “Log in with Google”) being the most familiar use case.
GitHub, Heroku, and Travis CI OAuth token theft
The first exploit on our list involves reusing stolen tokens from trusted integrations to scan, select, and steal from highly targeted GitHub repositories. Unlike most of the vulnerabilities we’ll discuss (which were disclosed by security researchers), this OAuth-based attack led to real damages affecting multiple organizations.
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 certain workflows, like deploying code living on GitHub to apps running on Heroku. The attacker stole these tokens and used them to bypass authentication on GitHub for the associated accounts.
The threat actor went on to list all the breached accounts’ organizations, showing a clear preference for certain targets. They were particularly interested in npm (Node Package Manager), which GitHub had acquired in 2020. After accessing npm’s private repositories, the attackers found AWS (Amazon Web Services) credentials that gave them access to npm’s web infrastructure. An unknown number of other organizations had their private repositories cloned, but the actual number of affected accounts remains confidential.
What did this pervasive attack teach us about OAuth security practices? Token security extends beyond your own implementation. While the 2022 GitHub/Heroku incident was clever, it exploited a simple and fundamental weakness in how the tokens were stored and protected by trusted service providers. To combat this, organizations should regularly audit their OAuth integrations for security oversights, like excessive scopes or token lifespans.
For apps looking to integrate with other services through OAuth (like GitHub in this example), follow token handling best practices:
Set clear scopes that follow the principle of least privilege.
Implement best practices for token rotation, server-side verification, and parameter validation.
Build capabilities to quickly detect and revoke compromised tokens.
For services integrating with platforms (like Heroku and Travis CI in this example):
Request only the minimum scopes needed for functionality.
Store tokens securely on both the server and client sides.
Prepare processes to respond if tokens are compromised.
Booking.com OAuth redirect manipulation
In late 2022, researchers at Salt Labs uncovered critical flaws in Booking.com’s OAuth implementation that centered 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 (in this case, Facebook) 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 potential 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 exposed authentication 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 Booking.com’s 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 underlying implementation flaw remained the same, placing the 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.
For developers and companies implementing OAuth-based authentication like the use case at Booking.com:
Validate all redirects against a strict, path-specific whitelist.
Never allow open redirects in any OAuth flow.
Carefully weigh how auth choices affect connected services (e.g., Kayak.com) and the possibility of increased attack surface.
Expo proxy vulnerability
Mid-2023, Salt Labs once again uncovered a critical flaw in a popular service’s OAuth implementation. This time, researchers examined the authentication proxy service for open-source dev platform Expo, a component used by hundreds of apps to implement OAuth. This issue stemmed from Expo’s auth.expo.io proxy service and its handling of return URLs—similar to redirect manipulation in its execution, but approaching 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. Attackers could create a malicious URL that, when clicked, would launch a legitimate OAuth flow through Expo’s auth.expo.io proxy. When authentication was completed, instead of returning to the legitimate application, the OAuth tokens would be sent to an attacker-controlled domain. With these tokens, a threat actor could potentially take over any user account on an app using Expo’s OAuth implementation.
The Expo incident underscored 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 highlights how a single security oversight in a widely-used platform can create systemic risks across connected apps.
For developers implementing OAuth, whether directly or through integration platforms:
Thoroughly vet third-party OAuth implementations to understand their security model.
Ensure proper validation for all parameters in OAuth flows.
Monitor token usage and build capabilities to to quickly deprecate or update compromised auth components.
Unify identities across OAuth providers by supplementing Expo with Descope.
Google OAuth domain takeover exploit
In September 2024, Truffle Security discovered an OAuth vulnerability in Google’s own “Sign in with Google” feature. The issue 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, the company has since reopened the ticket for investigation.
The vulnerability plays off a common scenario: startup company failure. When a startup goes under, its domain eventually expires. The domain becomes available for purchase again, 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.” That includes apps like ChatGPT, communication channels like Slack, and even HR systems containing sensitive personal information.
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. At the time of this blog's publication, Google is still investigating solutions to the exploit. However, a core part of the issue is due to other services relying on mutable identifiers (like email and domain) instead of the immutable sub claim. This claim is intended to be unchangeable, though some argue Google’s is not.
According to a source close to Truffle Security’s Ayrey, Google OAuth sub claims changed in about 0.04% of logins, causing hundreds of authentication failures per week. Because of this perceived inconsistency, connected 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.
For developers implementing OAuth authentication, this case provides several lessons:
Enforce additional identity verification beyond OAuth where possible (.e.g, adaptive MFA).
Don’t use mutable claims like email for authorization or verification
Be aware that, for expired domains affected by the issue, “Sign in with Google” may pose security risks.
Microsoft Azure Active Directory email claim misconfiguration (nOAuth)
In early 2023, Descope uncovered a critical flaw in how Microsoft Azure AD handles OAuth authentication–an issue we named "nOAuth.” The misconfiguration centers on a fundamental weakness in how Azure AD handles email claims in their OAuth implementation, allowing attackers to impersonate other email addresses without proving domain ownership. The exploit is similar to the previous Google OAuth domain hijacking example in that it abuses the email and domain parameters to impersonate a 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.
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, Microsoft released two new claims that would explicitly identify whether an email claim came from a domain-verified email and redact the email 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. To learn more about nOAuth, Descope discovery, and the resulting mitigation, you can read our complete disclosure and Microsoft’s statement regarding the vulnerability.
For developers implementing OAuth:
Use immutable identifiers (i.e., the
subclaim) instead of email addresses.Validate email ownership before merging accounts.
Implement proper domain verification.
Conclusion
OAuth is a powerful framework, but as these cases show, even the most trusted implementations can go wrong in complex and unexpected ways. Stolen tokens, redirect manipulation, domain takeovers, and email claim misconfigurations all stem from subtle weaknesses—whether in validation, third-party integrations, or reliance on mutable identifiers. The reality is that OAuth security is hard to get right, and even small mistakes can have serious consequences.
To reduce risk, you should lock down token security, enforce strict redirect validation, and avoid using mutable claims like email for authorization. Regular audits, proactive monitoring, and security-first design choices, like token rotation and adaptive MFA, are essential.
That said, securing OAuth isn’t just about following best practices, it’s an ongoing challenge that requires deep expertise. Instead of building and maintaining OAuth security from scratch, many turn to managed authentication services like Descope to handle the complexities for them. By offloading OAuth security to a dedicated provider, teams can focus on their core product while ensuring authentication is done right.
For more authentication and security tips, subscribe to our blog or follow us on LinkedIn.
