What Is OAuth Security? How OAuth 2.0 Vulnerabilities Let Attackers Steal Accounts

What Is OAuth 2.0

OAuth 2.0 is an authorisation framework that allows a third-party application to access resources on behalf of a user, without the user sharing their password with that application. It is the protocol behind every "Sign in with Google," "Continue with Apple," and "Connect your GitHub account" button on the web.

The core idea is delegation: instead of trusting a third-party app with your Google password, you authorise Google to tell that app "this user is who they say they are, and they have consented to share these specific pieces of information." Google issues a token that the app can use to retrieve the permitted information. Your password never leaves Google.

This is elegant in theory. In practice, OAuth 2.0 is a complex protocol with many moving parts — authorisation servers, resource servers, redirect URIs, state parameters, access tokens, refresh tokens, and several distinct flows for different contexts. Each of these moving parts can be misimplemented, and the consequences of misimplementation are severe: full account takeover, privilege escalation, and cross-site request forgery attacks that silently link a victim's account to an attacker's.

How the OAuth 2.0 Authorisation Code Flow Works

The most common OAuth flow — the authorisation code flow — works as follows:

1. The user clicks "Sign in with Google" on your application 2. Your application redirects the user to Google's authorisation endpoint, including your `client_id`, the `redirect_uri` where Google should send the response, the `scope` of access requested, and a `state` parameter you generated 3. The user authenticates with Google and consents to the requested permissions 4. Google redirects the user back to your `redirect_uri` with an authorisation `code` and the `state` parameter you sent 5. Your server exchanges the authorisation `code` for an access token by making a server-to-server request to Google, including your `client_secret` 6. Google returns an access token (and optionally a refresh token and ID token) 7. Your application uses the access token to retrieve the user's profile and create or log in their account

Each step in this flow has potential vulnerabilities if misimplemented.

Common OAuth Vulnerabilities

Missing or invalid state parameter (CSRF)

The `state` parameter is a random, unpredictable value that your application generates before initiating the OAuth flow and validates when the authorisation response returns. It is OAuth's defence against cross-site request forgery.

If the `state` parameter is missing, or if your application does not validate that the returned `state` matches what it sent, an attacker can perform a CSRF attack against the OAuth flow.

The attack: the attacker initiates an OAuth flow with the identity provider but does not complete it — instead, they capture the redirect URL that the identity provider would send back to your site (containing a valid authorisation code for the attacker's own account). They then trick a victim into visiting that URL. If your application does not validate `state`, it processes the authorisation code as if the victim had initiated the OAuth flow — and links the attacker's identity provider account to the victim's application account. The attacker can then log in as the victim by signing in with their own Google account.

Unvalidated redirect_uri

The `redirect_uri` in the OAuth request tells the identity provider where to send the authorisation code after the user authenticates. If your application does not strictly validate which redirect URIs are permitted, and the identity provider does not enforce an exact match against a registered list, an attacker can manipulate the redirect URI to point to a domain they control.

The attack: the attacker crafts an OAuth initiation URL with `redirect_uri=https://attacker.com/callback`. If the authorisation server validates this loosely — for example, checking only that the URI starts with your domain's root, which can be bypassed with `redirect_uri=https://yoursite.com.attacker.com` or an open redirect on your own domain — the authorisation code is sent to the attacker. The attacker exchanges the code for tokens and accesses the victim's account.

Open redirect chains

Your own application may have an [open redirect vulnerability](/blog/what-is-open-redirect-vulnerability) — a page that redirects users to a URL supplied in a query parameter without validating it. If your OAuth implementation allows a redirect_uri that includes a path with an open redirect on your own domain, an attacker can chain these: the identity provider sends the code to your domain (satisfying the domain check), and your open redirect immediately forwards it to the attacker's server along with the code in the URL parameters.

Authorisation code interception

In mobile applications using custom URI schemes (e.g., `myapp://callback`), multiple apps on the device can register the same URI scheme. A malicious app that registers the same scheme receives the authorisation code intended for the legitimate app. This is why mobile OAuth implementations should use PKCE (Proof Key for Code Exchange), which renders intercepted codes useless without the corresponding code verifier.

Token leakage via referrer header

If an access token is included in a URL — for example, passed as a query parameter to a page that loads third-party resources — the token appears in the `Referer` header of requests to those third-party resources. This is a token leakage vulnerability. Tokens should be stored in memory or in secure, HttpOnly cookies, never in URLs.

Insufficient scope validation

An OAuth access token is scoped — it grants access to specific resources or actions. A misimplemented resource server that does not validate the scope of an incoming token may accept a token scoped for read access and permit write operations, or accept a token scoped for one user's resources and return another user's data.

What Yrzo AI Tests

OAuth flows require authenticated testing and specific knowledge of which endpoints initiate and handle OAuth callbacks. A Yrzo AI [Professional scan (£399)](/checkout/standard) includes:

- Detection of OAuth callback endpoints - State parameter presence and validation testing - redirect_uri validation strictness - Open redirect detection on domains used in OAuth flows - Token handling in HTTP responses and headers

Related reading: [What Is CSRF Attack?](/blog/what-is-csrf-attack) · [What Is Open Redirect Vulnerability?](/blog/what-is-open-redirect-vulnerability) · [How to Secure an API](/blog/how-to-secure-an-api-uk)