At Axeploit, we often tell our clients that the most dangerous vulnerability isn't a complex buffer overflow or a zero-day in a kernel. It’s a design flaw in the logic of how "Person A" proves to "Service B" that they have permission from "Service C."
Back when Joel Spolsky was writing about the "Leaky Abstractions," he was talking about how TCP tries to pretend the network is reliable, even though it isn't. OAuth 2.0 is the ultimate leaky abstraction of identity. It tries to pretend that "Authorization" is the same as "Authentication," and it does so by wrapping complex cryptographic handshakes in simple HTTP redirects.
If you treat OAuth like a black box, that box is going to explode. Let's look at why your "secure" login is probably just a series of politely phrased suggestions that an attacker can ignore.
The Fundamental Misunderstanding: It’s Not a Password, It’s a Key Card
Before we dive into the wreckage, let’s get our terminology straight. OAuth 2.0 is about delegation. It’s the valet key for your car. You don't give the valet your ignition key (your password); you give them a restricted key that only lets them park the car.
The problem starts when developers use the valet key to open the bank vault.
When this flow is implemented perfectly, it’s a work of art. When it’s implemented by a developer under a deadline who just wants the "Login with GitHub" button to stop throwing 400 errors, it becomes a highway for account takeovers.
1. The Redirect URI Wildcard: The "Send My Mail to the Thief" Flaw
The most common, and arguably most devastating, pitfall is the loose validation of the redirect_uri.
In the OAuth flow, after the user authenticates with the provider (like Google), the provider sends an authorization code back to the client via a redirect. The client tells the provider where to send this code using the redirect_uri parameter.
The Error: Many developers use wildcards (e.g., https://*.axeploit.com/*) or simple prefix matching to save time.
The Exploit: If an attacker can find a single open redirect or even a page they control on a subdomain (like https://dev-test.axeploit.com), they can craft an OAuth link that sends the victim’s authorization code directly to the attacker’s server.
Axeploit Insight: If your OAuth provider allows localhost redirects in production, or if you aren't using exact-match string comparison for URIs, you aren't using a redirect; you're using a leak.2. The Missing 'state' Parameter: CSRF for Authentication
If you aren't using the state parameter, your OAuth implementation is vulnerable to Cross-Site Request Forgery (CSRF).
The Error: The state parameter is an opaque value used by the client to maintain state between the request and callback. Developers often omit it because the flow "works" without it.
The Exploit: An attacker starts the OAuth flow on your site but stops right before the callback. They take the callback URL (containing their authorization code) and trick a logged-in victim into clicking it. The victim’s account on your site is now linked to the attacker’s identity at the provider.
The next time the attacker logs in via OAuth, they are logged into the victim’s account. No password needed. No alerts triggered.
3. Implicit Grant: The Ghost of Security Past
The Implicit Grant flow was designed for single-page apps (SPAs) back when Cross-Origin Resource Sharing (CORS) was difficult. It returns an Access Token directly in the URL fragment.
The Error: Using Implicit Grant in 2026.
The Exploit: Access tokens in URLs are logged everywhere: browser history, proxy logs, and Referer headers. If a victim clicks a link to an external site from your "secure" dashboard, that external site now has the victim’s access token.
The Axeploit Rule: Implicit Grant is deprecated for a reason. Use Authorization Code Flow with PKCE (Proof Key for Code Exchange). If your architect says otherwise, show them the door.
4. PKCE Downgrade Attacks: Stealing the Code in Transit
Speaking of PKCE, it was designed to prevent authorization code injection. It involves the client creating a high-entropy secret (code_verifier) and sending a hash of it (code_challenge) in the initial request.
The Error: The server supports PKCE but doesn't enforce it.
The Exploit: An attacker intercepts the initial request and simply removes the code_challenge. If the authorization server is "backwards compatible" and allows the request to proceed without PKCE, the attacker can later use a intercepted authorization code without knowing the verifier.
5. Token Substitution: The "Wrong App" Attack
This is a subtle one that often happens in mobile apps or distributed systems.
The Error: A backend accepts an ID Token or Access Token without verifying the aud (audience) claim.
The Exploit: An attacker gets a valid token from a different app (App B) that uses the same identity provider. They then send that token to your app (App A). If your app only checks "Is this a valid token from Google?", it will log the attacker in. You must check: "Is this a valid token from Google intended specifically for Axeploit?"
6. The "Scope Creep" and Over-privileged Tokens
Developers often ask for the * or all scope because it's easier than figuring out exactly which permissions they need.
The Error: Requesting excessive scopes (e.g., repo, gmail.read) when you only need email.
The Exploit: If your client secret is ever leaked, or if a user’s token is intercepted, the blast radius is catastrophic. An attacker doesn't just get the user's name; they get their private code repositories or their entire inbox.
[Image showing OAuth scope privilege escalation]
7. Insecure Storage of Client Secrets
This is the "Secret in the Source Code" classic.
The Error: Hardcoding the client_secret in a mobile app, a frontend JavaScript file, or a public GitHub repo.
The Exploit: Once the secret is public, the attacker can impersonate your application entirely. They can swap codes for tokens, refresh tokens, and manipulate the flow at will.
Axeploit Pro Tip: Client secrets belong in environment variables or hardware security modules (HSMs). If it’s in your .js bundle, it’s not a secret; it’s a gift to the internet.
8. Refresh Token Persistence and Rotation
Refresh tokens are long-lived. If they aren't handled with extreme care, they are a permanent back door.
The Error: Not implementing Refresh Token Rotation.
The Exploit: If an attacker steals a refresh token, they can generate new access tokens indefinitely. Without rotation (where a new refresh token is issued with every use and the old one is invalidated), you have no way to detect the theft until the user manually revokes access.
The Axeploit Checklist for Secure OAuth
At Axeploit, we don't just point out holes; we help you build better foundations. If you want to avoid being the next headline, your OAuth implementation must follow these rules:
- Use PKCE Always: Regardless of whether the client is "public" or "confidential."
- Exact Match Redirects: No wildcards. No exceptions.
- Mandatory State: Validate it on every single callback.
- Validate the Audience: Ensure the
audclaim matches your Client ID. - Rotate Your Refresh Tokens: Treat them as highly sensitive, single-use credentials.
- Principle of Least Privilege: Ask for the absolute minimum scope required for the task at hand.
Final Thoughts: Software is Still Hard
Joel Spolsky once wrote that "Good software takes ten years." Security takes even longer because the target is always moving. OAuth 2.0 was supposed to make our lives easier, but by abstracting the "hard stuff," it created a generation of developers who don't understand how identity actually works.
Don't be the developer who trusts the black box. Open it up, look at the redirects, validate the signatures, and remember: in the world of OAuth, if you aren't verifying, you're just hoping.
