Link Search Menu Expand Document

Broken OAuth

  1. Broken OAuth
  2. Description
  3. Impact
  4. Scenarios
    1. Unchecked or too lax redirect URI
    2. Lack of state check
    3. Implementing the Authorization Code flow in a browser-based application
  5. Prevention
    1. Testing
  6. References


The Open Authorization Framework (OAuth) is an open-standard security framework that enables clients to be authenticated by participating website and application servers (resource providers) via third-party services (identity providers) in a process referred to as secure designated access. Enabling API integration for third-party authorization/single sign-on (SSO) delegation services with major internet platforms such as Amazon, GitHub, Google, Facebook, LinkedIn, Microsoft, PayPal, Spotify, Twitter, etc., has become standard practice in modern site and app development.

There are a number of relevant entities in an OAuth access process:

  • Resource owner (an end user with protected resources, i.e., data in the form of emails, photos, contact lists, etc.).
  • Client (generally an application/site seeking access to resources).
  • Authorization server (the entity delegated by the client to access resources).
  • Resource server (the server charged with the protection of the resource owner’s data).

OAuth is designed to gain the resource owner’s permission by requesting access to user-controlled resources hosted on the resource server. In addition, end users can authorize third-party access sans credential-sharing, i.e., without having to enter usernames and passwords.

The OAuth permission process itself is performed in different flows (called “grant types”) that include:

  • An authorization code grant.
  • The resource owner’s password credentials grant.
  • An implicit grant.
  • The client credential grant.

All of these can be exploited in some way directly or in concert with other attack techniques (including CSRF, XSS, and open redirect). Attacks manipulating the GET requests, duplication, and covert redirection of the authorization code are all known vectors. The most common attacks on OAuth include:

  • The Authorization code being used more than once.
  • Redirect URI not being validated.
  • Cross-site request forgery OAuth Client.


The fallout from having a delegated authorization application commandeered by a malicious actor can lead to complete data compromise, a loss of integrity and confidentiality in the app/server, and potentially collateral attacks, such as fraud and identity theft. Given the types of firms that integrate OAuth for their sign-on requirements and the fact that compromise can likely mean direct account access, it is no surprise that, on the malicious side of the fence, there are evermore persistent advancements in effective OAuth attacks. Fake Google phishing pages, vulnerabilities threatening Microsoft Azure accounts and token theft in Facebook are a handful of numerous attacks known to the public.


Unchecked or too lax redirect URI

When, either for convenience or by mistake, the check on the valid redirect URI is missing or non-restrictive enough, the application is exposed to several attacks. In particular, this flawed check allows an attacker to conduct a phishing campaign where victims are redirected to a malicious website that mimics the legitimate login form of the authorization server. An inattentive victim might fall prey to this trick and insert their credentials, which ultimately will be captured by the attacker.

Lack of state check

During its flow, the OAuth standard permits a state parameter that acts as a CSRF token to piggyback on the process; unfortunately, applications that fail to use this feature expose themselves to CSRF attacks. In the OAuth context, a CSRF attack might manifest itself in the form of an attacker (although note the attacker is a legitimate user of the application) commencing, but not completing, the authentication process with the goal of finding a victim that does just that - completes the process. When this happens, the victim ends up logged in as the attacker. Yet again, an inattentive victim might not notice this and use the application as usual, possibly in a way that exposes some sensitive information, e.g., by uploading some photos.

Implementing the Authorization Code flow in a browser-based application

The Authorization Code flow cannot be implemented securely in a browser-based (i.e., without any server-side support) application as it hinges on the fact that the application stores the client secret. Browser-based applications are unable to store secrets, and an attacker will eventually be able to find it, no matter how obfuscated the JavaScript code is. With knowledge of the client secret, an attacker might be able to create rogue versions of the legitimate application that will authenticate successfully against the authorization server, thanks to the client secret.


Since there are multiple, different ways of compromising the OAuth framework, pinning down any set of preventative measures results in a long list given the number of complimentary attack methods used in the attack arsenal. The following points attempt to cover the most pressing and available actions administrators can do to prevent OAuth exploitation:

  • The client must not use the authorization code more than once. In the event an authorization code is used, the request must be denied by the authorization server, and all tokens previously issued on that particular authorization code should be revoked.
  • Native applications are not recommended to use the implicit grant.
  • Clients must enforce the check on valid redirect URIs provided by the Authorization server without resorting to catch-all domains.


Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.


IETF - The OAuth 2.0 Authorization Framework

IETF - OAuth 2.0 Threat Model and Security Considerations

IETF - OAuth 2.0 Security Best Current Practice

Dhaval Kapil - Attacking the OAuth Protocol

Aaron Parecki - OAuth 2 Simplified