Spot the OAuth misconfiguration in this MCP server implementation

The bug is in the **token exchange** step. The server redeems the authorization code for a token without checking the PKCE pair. PKCE is short for Proof Key for Code Exchange. Here is how PKCE is supposed to work. When the flow starts, the client invents a random secret called the `code_verifier`. It hashes that secret into a `code_challenge` and sends only the challenge to the identity provider. Later, when redeeming the code, the client sends the original verifier. The provider re-hashes it and confirms it matches the challenge from step one. This server skips that final check. So if an attacker intercepts the authorization code, say through a logged URL or a malicious redirect, they can redeem it themselves. The server has no way to tell the real client apart from the thief. The damage is amplified because the MCP server holds broad credentials. The attacker rides the server's identity to reach scopes far wider than any single user should have. That is the confused-deputy pattern.

The flaw is the missing PKCE verification at token exchange. **PKCE** binds the start of the OAuth flow to its end. The client generates a random `code_verifier`, hashes it into a `code_challenge`, and sends only the challenge up front. At redemption it presents the raw verifier. The provider re-hashes and confirms the match. This server exchanges the code without that check. An attacker who intercepts the authorization code can redeem it directly. Code interception is realistic for MCP servers. Codes leak through logs, referrer headers, or a malicious server in the chain. The MCP angle makes it worse. The server exchanges the code under its own identity and holds broad credentials. So a stolen user code becomes access at the server's privilege level. That is a confused deputy. A privileged component is tricked into acting for an attacker. The fix is to enforce PKCE and verify the verifier server-side before issuing a token. You should also bind tokens to an audience and avoid passing one static token across users. Per-user tokens plus explicit consent keep the blast radius scoped to the individual, not the server.