OAuth 2.0 sits at a uniquely valuable intersection: it hands out access to real user data, it moves through browsers and redirects that attackers can influence, and it’s implemented slightly differently by thousands of different companies. That combination makes it a rich target.

Unlike attacking a single server directly, attacking OAuth often means attacking the handshake between systems — the moment when trust is being established and handed off from one party to another. Every redirect, every token, and every consent screen is a small opportunity for something to go subtly wrong. Most successful OAuth attacks don’t break any cryptography at all; they exploit a missing check, a loose comparison, or a developer’s reasonable-sounding shortcut.

The authorization code is meant to be a brief, one-time-use hop between the Authorization Server and the Client. If an attacker can grab it during that hop, they may be able to trade it for a real access token.

On mobile devices, this interception often happens through malicious apps registering the same custom URL scheme as the legitimate app, so the operating system delivers the redirect — and the code inside it — to the attacker’s app instead of (or in addition to) the real one.

If an Authorization Server checks a redirect address loosely — say, only the domain, not the full exact path — an attacker can smuggle the authorization code out to a server they control.

The classic version of this attack uses an “open redirect” — a page on the legitimate site that forwards visitors to any URL supplied in a query parameter. An attacker crafts a login request whose redirect URI points to this forwarding page, then sets the forwarding target to their own server, catching the authorization code as it passes through.

In this attack, someone tricks your browser into completing an OAuth login flow that was actually started by the attacker — potentially linking your account to the attacker’s identity instead of your own.

Here’s the trick: the attacker begins their own login flow with a legitimate service, gets as far as receiving a valid authorization code addressed to the real callback URL, but instead of finishing it themselves, they send that exact callback link to a victim — perhaps embedded in an image tag on a malicious webpage. If the victim’s browser loads that link, the victim’s session gets bound to the attacker’s authorization flow, sometimes resulting in the victim’s account becoming linked to the attacker’s third-party account without realizing it.

Some older or poorly configured OAuth setups pass tokens directly in the URL, where they can linger in browser history, server logs, or the “Referer” header sent to other websites.

This is one of the core reasons the modern, recommended flow uses a short-lived authorization code exchanged through a direct, server-to-server call, rather than putting the actual access token straight into the browser’s address bar. An older variant called the “Implicit flow” did exactly that, returning tokens directly in the URL fragment — and it’s now widely discouraged for this very reason.

Not every attack targets the protocol’s mechanics — some target the human standing in front of the consent screen, tricking them into approving far more access than they realize.

In a consent phishing attack, an attacker registers their own legitimate-looking application with a real Authorization Server (such as Google or Microsoft’s platform), then sends victims a convincing email urging them to “verify their account” or “view a shared document” through a link that starts a real OAuth consent flow — for the attacker’s app. Because the login screen and domain genuinely belong to the trusted provider, victims often don’t notice that the permissions being requested (read all email, access all files, send messages as you) are far broader than anything a document viewer would need.