OAuth Attacks

Using a common authentication mechanism to compromise users

Introduction

OAuth is widely used across modern web applications and cloud services to allow users to grant applications controlled access to their accounts without giving those applications their passwords. While OAuth provides a secure framework for delegated access when correctly implemented, weaknesses in the implementation or configuration can create opportunities for attackers to steal authorization codes, access tokens, or trick users into granting access to malicious applications.

What is OAuth?

OAuth (Open Authorization) is an authorization framework that allows one application to access resources belonging to a user on another service without the user having to share their password.

For example, when a website offers

“Sign in with Google”…

the application can use OAuth to request permission to access specific information associated with the user’s Google account.

OAuth separates authentication from authorization.

Instead of giving the third-party application your password, the authorization server issues a token that represents the permissions you have granted.

A simplified OAuth flow looks like this:

User → Application → Authorization Server → User Consent → Authorization Code → Access Token → Protected Resource

The access token is then presented by the application when it needs to access the user’s protected resources.

OAuth is therefore commonly used for:

  • Delegated access to APIs
  • Single sign-on integrations
  • Cloud applications
  • Mobile applications
  • Third-party application integrations
  • “Sign in with…” services
  • Access to services such as email, storage and calendars

OAuth itself is an authorization framework, rather than an authentication protocol. OpenID Connect builds an authentication layer on top of OAuth for situations where an application needs to establish who the user is.

How OAuth attacks work

OAuth attacks generally target weaknesses in the implementation, configuration or handling of OAuth flows, rather than breaking the cryptography behind OAuth itself.

Attackers may attempt to manipulate authorization requests, redirect users to malicious locations, steal authorization codes or tokens, or trick users into granting excessive permissions.

1. Authorization Code Interception

In the authorization-code flow, the authorization server returns an authorization code to the application.

The application then exchanges this code for an access token.

If an attacker can intercept or obtain the authorization code, they may attempt to exchange it for a valid access token.

This can occur when:

  • Redirect URIs are poorly protected
  • HTTPS is not correctly enforced
  • Authorization codes are exposed through URLs
  • PKCE is not implemented where appropriate
  • Codes are not properly bound to the originating transaction

2. Redirect URI Manipulation

OAuth relies heavily on the redirect URI – After authentication and authorization, the authorization server redirects the user’s browser back to a registered location.

If an application accepts an attacker-controlled or insufficiently validated redirect URI, the attacker may be able to redirect the authorization response to infrastructure they control.

For example:

Legitimate OAuth request → Authentication → Malicious redirect → Authorization code exposed

This is why modern OAuth security guidance recommends exact redirect URI matching rather than overly broad wildcard or pattern matching.

3. Open Redirector Abuse

An open redirector is a legitimate website endpoint that allows a user to specify an arbitrary destination.

For example: legitimate-site.com/redirect?url=attacker-site.com

An attacker may combine an open redirector with weaknesses in an OAuth implementation. The victim initially sees a legitimate domain, but is ultimately redirected somewhere controlled by the attacker.

This can potentially be used to:

  • Steal authorization codes
  • Expose access tokens
  • Conduct phishing attacks
  • Bypass user trust in legitimate domains

OAuth security guidance specifically recommends that clients and authorization servers do not expose open redirectors.

4. Authorization Code Injection

OAuth authorization codes are intended to be associated with a particular authorization transaction.

In an authorization-code injection attack, an attacker attempts to cause a legitimate application to process an authorization code that was generated for a different transaction or attacker-controlled session.

The result can be particularly dangerous when the application fails to properly bind the authorization response to the session that initiated it.

PKCE (Proof Key for Code Exchange) provides an important defence against this type of attack by binding the authorization code exchange to a secret verifier known to the legitimate client instance.

5. OAuth CSRF Attacks

OAuth flows can also be vulnerable to Cross-Site Request Forgery (CSRF). Here, an attacker may attempt to cause a victim’s browser to complete an OAuth flow that the victim did not intentionally initiate.

This can result in the application associating the wrong account or authorization with the victim’s session.

Security mechanisms such as:

  • state
  • PKCE
  • OpenID Connect nonce

can provide protection against different forms of request forgery and transaction manipulation.

6. Token Theft

The ultimate target of many OAuth attacks is the access token. An access token represents permission to access protected resources and if an attacker obtains a valid token, they may be able to use it without knowing the user’s password.

Tokens can potentially be exposed through:

  • Browser history
  • Logs
  • Referrer information
  • Insecure applications
  • Misconfigured redirect URIs
  • Browser extensions or malicious scripts
  • Poorly protected client storage

The permissions contained within the token determine what the attacker can access.

7. Excessive OAuth Permissions

OAuth applications request scopes defining what they are allowed to access.

For example Application → Request: Read email

The user then grants the requested permission. A malicious or compromised application may request considerably more access than it actually requires.

This creates a major security problem because a stolen token may provide an attacker with much greater access than necessary.

Examples include permissions allowing an application to:

  • Read email
  • Modify files
  • Access contacts
  • Access calendars
  • Perform administrative actions
  • Maintain long-term access through refresh tokens

This is why OAuth permissions should follow the principle of least privilege.

8. Phishing Through Malicious OAuth Applications

OAuth can also be abused as part of phishing campaigns. Instead of asking the victim to provide their password directly, an attacker may create a malicious application that requests access to legitimate services.

The victim may see a familiar authorization page and approve the requested permissions. The attacker then receives the resulting authorization credentials.

This technique can be particularly effective because the victim may never actually provide their password to the attacker.

Why OAuth attacks matter

OAuth attacks demonstrate an important principle in modern security:

You do not necessarily need the user’s password if you can obtain their authorization.

A compromised OAuth token can sometimes provide access to valuable resources without requiring the attacker to authenticate with the victim’s password.

The consequences can include:

  • Account compromise
  • Data theft
  • Email access
  • Cloud storage access
  • Credential theft
  • Persistent application access
  • Lateral movement
  • Further compromise of connected services

How to defend against OAuth attacks

Secure OAuth implementations should incorporate multiple protections.

  • Use Proof Key for Code Exchange (PKCE) – PKCE should be used to protect authorization-code flows, particularly for public clients. Current OAuth security guidance requires authorization servers to support PKCE and recommends its use more broadly.
  • Validate Redirect URIs – Use exact redirect URI matching wherever possible. Avoid broad wildcard patterns and never allow users to specify arbitrary redirect destinations.
  • Protect OAuth State – Use transaction-specific state values where required to prevent request forgery and ensure OAuth responses belong to the correct session.
  • Minimise Scopes – Applications should request only the permissions they actually require.
  • Protect Tokens – Access and refresh tokens should be treated as sensitive credentials.
  • Monitor OAuth Applications – Organisations should monitor new OAuth applications, unusual consent grants, excessive permissions, suspicious token usage, unexpected geographic locations, long-lived refresh tokens, and applications accessing sensitive resources

Conclusion

OAuth provides a powerful mechanism for delegated authorization, allowing applications to access resources without requiring users to share their passwords. However, OAuth introduces another set of credentials and trust relationships that attackers can target.

Poor redirect URI validation, authorization-code manipulation, CSRF, token theft, excessive permissions and malicious applications can all turn OAuth into an attack pathway.

The fundamental security principle is:

Protect the authorization flow, protect the tokens, restrict permissions and never blindly trust OAuth requests or redirects.

Modern OAuth security guidance, including RFC 9700, specifically addresses these threats and recommends protections such as exact redirect URI matching, PKCE, CSRF protection and restricted access tokens.