So I went down the rabbit hole on OAuth 2.0 — not the “click ‘Sign in with Google’ and copy a token” version, but the why does every modern spec keep adding more layers on top of it version. What I found is that the protocol I thought I knew is actually three separate ideas stacked on top of each other, each one a response to an attack the previous one couldn’t see coming.

This post is what I wish I had read before I started reading the RFCs. Let’s begin with the part everyone thinks they know.

The Three-Legged Dance

Before OAuth, sharing data between apps was barbaric. If you wanted a calendar app to read your Gmail, you handed it your Gmail password. The calendar app got full access, forever, to everything. Lose trust in the app? Change your Google password and pray you remembered every other app you gave it to.

OAuth 2.0 fixed this with a deceptively simple idea: never share the password — share a scoped, revocable, time-limited token instead. Three actors are involved: the user (resource owner), the client app that wants to act on the user’s behalf, and the authorization server that knows who the user is. (Plus the resource server holding the data, which just trusts the auth server.)

Here is the flow, stripped to its essentials:

The key move is step 4. The auth server does not hand the access token directly to the client. It hands the user’s browser a short-lived authorization code, and the browser delivers it to the client. The client then trades that code (plus its client_secret) for the real token over a back-channel call the user's browser never sees.

This front-channel code, back-channel token split is what makes the original flow safe. The token never touches the address bar, never lands in browser history, never shows up in a referrer header.

Hold on — anyone can hit /authorize?

The first time I traced this, I had a sinking feeling. The client_secret only appears at step 5. Step 2 is just a URL the browser visits. The client_id is public — literally embedded in every "Sign in with Google" button on the internet. So what stops an attacker from crafting their own /authorize URL with my app's client_id?

The answer is the part of OAuth nobody talks about loudly enough: the security boundary is the registered redirect_uri, not the client_id.

When you register a client, you hand the auth server an exact list of allowed redirect URIs. From then on, the auth server will only deliver codes to one of those URIs:

• Attacker sets redirect_uri=https://evil.com/steal → not in the allowlist → request rejected before a login page is ever shown.
• Attacker sets the legit redirect_uri=https://myapp.com/callback → the code lands at the real app's server. The attacker never sees it.

The auth server isn’t trying to authenticate who is asking. It just controls where the result goes. That’s a subtle but profound design choice: client_id is an identifier, not a credential. At /authorize, identification is all you need, because the delivery address is what matters.

Modern auth servers enforce exact-match redirect URI validation. No regex, no “starts with,” no “same host” — exact string match. The whole argument collapses if you allow wildcards there.

This worked beautifully for server-side web apps. Then mobile happened.

When Mobile Broke It

Mobile apps, SPAs, CLI tools, AI agents — suddenly the “client” was no longer a server you controlled. It was an iPhone app, a React bundle in a browser, a Python script on someone’s laptop.

These are public clients. They cannot keep a secret. A client_secret baked into an iOS binary is one strings command away from anyone. A secret in a JavaScript bundle is just... served to the world.

That alone would have been bad. But mobile gave us a second, sneakier problem.

The legitimate app kicks off OAuth with a redirect to myapp://callback. The user logs in, the auth server tries to deliver the code — but on most mobile OSes, any app can register that custom URI scheme. If a malicious app got there first, the OS may happily hand the code to the attacker instead. With no real client_secret to differentiate the two apps, the auth server can't tell impostor from real.

The redirect URI defence from the previous section doesn’t help here. Both apps are claiming the same URI.

Enter PKCE (RFC 7636, pronounced “pixy”)

PKCE — Proof Key for Code Exchange — fixes this with a beautifully simple idea: let the client prove, at token-exchange time, that it is the same instance that started the flow, without needing a pre-shared secret.

1. Before kicking off the flow, the client generates a random code_verifier — say, 64 bytes that only live in memory.
2. It hashes the verifier with SHA-256, base64url-encodes the result, and calls that the code_challenge.
3. The auth request carries the code_challenge (not the verifier).
4. The auth server stores code ↔ challenge.
5. At token exchange, the client must produce the original code_verifier.
6. The auth server hashes it, compares to the stored challenge, and only issues a token if they match.

The attacker who intercepts the code never sees the verifier. SHA-256 is one-way, so they can’t derive it from the challenge either. The stolen code is a dead letter.

What PKCE actually proves

Crucial mental model: PKCE does not authenticate the client. Anyone with a known client_id can still start a PKCE flow with their own challenge. PKCE proves something different — and arguably more important:

PKCE welds the two ends of one flow together. Whoever finishes at /token is the same party who started at /authorize.

That property defeats both code interception (the attack above) and code injection (an attacker splicing their own code into a victim’s callback). The verifier you generated at the start is the only thing that lets you finish.

Two practical notes:

• Always use S256, never plain. plain exists only for ancient platforms with no SHA-256.
• PKCE and state solve different problems. state stops injection from outside (CSRF on the callback); PKCE stops interception of the result. Use both.

“But my server can keep a secret — why PKCE there?”

If your client is a confidential web app that holds a client_secret, doesn't the secret already do what PKCE does? Mechanically, yes — but PKCE protects against three things the secret alone cannot:

1. Secret leaks happen — committed .env files, log lines, container layers. The per-flow verifier was never persisted; a leaked secret alone is not enough to redeem stolen codes.
2. Authorization-code injection. An attacker tricks a victim’s browser into completing the legit server’s callback with the attacker’s code, binding the victim’s session to the attacker’s account. The verifier mismatch shuts that down server-side.
3. Codes leak through paths the secret doesn’t cover — open redirects, referrer headers, broken proxies. The secret protects only the token endpoint.

How does PKCE work when the client is a server? The verifier lives server-side — in a session store, Redis, or a signed cookie — keyed by state. The browser never sees it.

Both the client_secret and the code_verifier are validated on /token. Belt and suspenders. This is why OAuth 2.1 now mandates PKCE for every authorization-code flow.

So PKCE locks down the handshake. Are we done?

Not quite.

And Then Tokens Get Stolen

Here is the dirty secret that took me a while to internalise: once the token is issued, OAuth 2.0 stops protecting you.

An access token is a bearer token. It is literally a string. Whoever holds it, uses it. The resource server checks the signature or runs introspection and grants access. It does not care who is sending the request.

That is fine if your token always travels over TLS, never gets logged, never sits in a proxy, never lives in browser memory next to a malicious extension, never gets exfiltrated by a compromised dependency. In a system like an MCP gateway — where an agent’s runtime, the user’s machine, multiple downstream APIs, and a half-dozen libraries are all in the request path — that assumption gets shaky fast.

If an attacker grabs the token, they can replay it from anywhere until it expires. PKCE does nothing here; PKCE protected the handshake. The token is already out.

Enter DPoP (RFC 9449)

DPoP — Demonstrating Proof-of-Possession — was finalised in September 2023 and is rapidly becoming the answer for public clients (which, in 2026, includes basically every AI agent). The MCP spec calls it out explicitly as the recommended hardening. So this one hits very close to home.

The idea: bind the token to a key only the client has. Make it sender-constrained. A stolen token without the matching private key is just bytes.

1. Once, at startup, the client generates an EC P-256 key pair. The private key stays on the device. Forever.
2. For every token request, the client signs a short-lived JWT — a DPoP proof — with its private key and sends it in a DPoP: header.
3. The auth server verifies the proof and issues an access token carrying cnf.jkt — the SHA-256 thumbprint of the client's public key. The token is now bound to that key.
4. For every API call, the client signs a fresh proof — this time also including ath, a hash of the access token being presented.
5. The resource server checks that cnf.jkt matches the public key in the proof and that the proof's signature is valid for this exact request.

Let’s open up the envelopes

The summary above hides what is actually on the wire. Here is what the JWTs look like at each hop, drawn straight from RFC 9449:

Four things to notice in the JSON:

• The public key travels with every proof, in the JOSE header (jwk). No JWKS endpoint needed. The resource server verifies the signature with the embedded JWK, then checks its SHA-256 thumbprint against cnf.jkt. Self-contained.
• htm and htu make proofs per-request. A proof minted for GET /resource cannot be reused for POST /transfer.
• ath binds the proof to one specific token. Stolen proof + different token = rejected.
• jti enables replay detection. Resource servers cache seen jtis for the proof's validity window; duplicates get 401'd.

Even with the access token and a captured proof in hand, an attacker is stuck with one specific request, on one specific token, within a tiny time window — and replay detection catches the second attempt.

A few subtleties I found genuinely elegant:

• Refresh tokens get bound too. Stealing a refresh token without the private key is useless.
• Optional server-issued DPoP-Nonce shrinks the replay window further.
• No PKI. Unlike mTLS, there are no certificates to manage. The client just generates a key pair locally. Huge for AI agents and CLIs.

This changes the threat model entirely. Even if a downstream tool, a logging pipeline, or a buggy library leaks a token, the leak is inert. The attacker would also need the private key, which never leaves the client.

Putting It Together

Three mental models worth holding onto:

1. client_id is an identifier, not a credential. Public clients are inherently unauthenticated; the protocol relies on controlled delivery (redirect URI) instead.
2. PKCE doesn’t authenticate the client. It welds the two ends of one flow together. A weaker-sounding guarantee than authentication, but exactly the right one for public clients.
3. DPoP shifts the question from “is this token valid?” to “is this token in the right hands right now?” This is the layer that finally protects you from your own infrastructure leaking.

Each layer assumes the previous one and patches a class of attack that became possible only when the world changed — mobile apps for PKCE, AI agents and sprawling service meshes for DPoP. If you are touching identity in 2026 — building an MCP gateway, shipping an AI agent, or wiring up any public client — you probably want all three. PKCE is table stakes. DPoP is the part that lets you sleep at night.

Further Reading

• RFC 6749 — OAuth 2.0
• RFC 7636 — PKCE
• RFC 9449 — DPoP
• RFC 9700 — OAuth 2.0 Security Best Current Practice
• The MCP authorization spec — leans on OAuth 2.1 and points at sender-constrained tokens as the future.