Common MCP OAuth Misconfigurations

An MCP OAuth misconfiguration is a mistake in how an MCP client, server or authorization server handles sign-in and tokens. The protocol's authorization rules are sound. The problems come from skipping a check, loosening a rule for convenience, or trusting a URL that a server supplied.

The stakes are high because MCP tokens open real systems: email, files, CRMs, payments. The MCP authorization specification builds on OAuth 2.1 and adds MCP-specific rules. Its companion security considerations page lists what implementations MUST do.

This page walks through the most common mistakes and the rule that prevents each one. It reflects the 2026-07-28 spec, the latest as of October 2026. Sources were checked on 28 October 2026.

The ten most common misconfigurations

1. Skipping audience validation

A server accepts any valid-looking token, even one issued for another service. The spec says servers MUST validate that tokens "were issued specifically for them as the intended audience." Invalid or expired tokens MUST get HTTP 401.

2. Token passthrough

A server forwards the client's token to a downstream API. The spec is blunt: servers "MUST NOT accept or transit any other tokens." If the server calls an upstream API, it uses a separate token from that API's own authorization server. See why MCP servers must not pass tokens through.

3. Leaving out the resource parameter

Clients MUST send the RFC 8707 resource parameter in both authorization and token requests. It names the exact MCP server the token is for. The spec says clients MUST send it "regardless of whether authorization servers support it."

4. Weak or missing PKCE

PKCE stops stolen authorization codes from being redeemed. Clients MUST implement it and MUST use S256 when technically capable. If the authorization server's metadata lacks code_challenge_methods_supported, clients "MUST refuse to proceed."

5. Ignoring the iss check

A client that talks to many authorization servers can be tricked into sending a code to the wrong one. This is a mix-up attack. Clients MUST record the expected issuer and compare it to the iss value in the response, per RFC 9207. The best practices page notes that "PKCE alone does not prevent this attack."

6. Loose redirect URI matching

Wildcards or prefix matching let attackers redirect codes to their own site. Authorization servers MUST "validate exact redirect URIs against pre-registered values." Proxy servers MUST use "exact string matching (not pattern matching or wildcards)."

7. No per-client consent on proxy servers

An MCP server that fronts a third-party API with one static client ID can be abused. The best practices page explains how a consent cookie lets an attacker skip the consent screen. Proxy servers MUST keep per-client consent before forwarding. This is the confused deputy problem.

8. Opening authorization URLs unsafely

A malicious server can supply an authorization URL that runs code. Clients MUST only allow https:// (or http:// for loopback in development). They MUST reject javascript:, data:, file: and similar schemes, and MUST NOT open URLs through shell commands.

This is not hypothetical. JFrog's research on mcp-remote (CVE-2025-6514) showed a malicious server returning a crafted authorization_endpoint. On Windows, the value reached a PowerShell command and ran. Versions 0.0.5 to 0.1.15 were affected. Version 0.1.16 fixed it.

9. Requesting every scope up front

When a client asks for every scope in scopes_supported, a stolen token can do everything. The best practices page warns against "wildcard or omnibus scopes (*, all, full-access)." It recommends a minimal starting set, with step-up through insufficient_scope challenges.

10. Trusting server-supplied discovery URLs

During discovery, clients fetch URLs that a malicious server controls. Without checks, those URLs can point at internal systems. See SSRF in MCP.

An illustrative example

This scenario is illustrative, not a real incident.

A startup builds an MCP server that wraps its customers' Google Drive. To ship faster, the server accepts the access token the client sends and forwards it to Google. It never checks the token's audience.

An attacker who obtained a Google token issued for a different app sends it to the MCP server. The server accepts it and lists the victim's files. Logs at Google show requests from the MCP server, not from the attacker, which slows the investigation.

Who is at risk

• Teams building remote MCP servers, especially proxies in front of third-party APIs.
• Client developers handling discovery, redirects and URL opening.
• Companies running their own authorization servers for MCP, including those accepting Client ID Metadata Documents.
• Users of older bridge tools, such as outdated mcp-remote versions.

How to detect it

• Send a token issued for a different audience to your server. It should return 401.
• Try a redirect URI that differs by one character. The authorization server should reject it.
• Check client code for exec, shell, or cmd.exe calls used to open URLs.
• Review the scopes your client requests. Compare them with what each workflow needs.
• Check bridge and SDK versions against published advisories.

How to reduce the risk

Client side

• Implement PKCE with S256, send resource, validate iss, and validate state.
• Open URLs only through platform APIs, never through a shell, and only for allowed schemes.
• Start with minimal scopes and keep a cap on step-up retries. The spec says clients SHOULD implement retry limits.
• Use Client ID Metadata Documents where supported. The client registration page says Dynamic Client Registration "is deprecated."

Server side

• Validate every token's audience, issuer and expiry before doing anything.
• Never forward the client's token. Obtain your own upstream tokens.
• Publish Protected Resource Metadata, which the spec makes a MUST.
• Emit precise scope challenges, not the full catalog.

Organization side

• Prefer short-lived access tokens. The spec says authorization servers SHOULD issue them.
• Rotate refresh tokens for public clients, which the spec makes a MUST.
• Have OAuth changes reviewed by someone who knows the spec. Our MCP authentication and OAuth guide explains the full flow.

What the spec says

The authorization spec says implementations "MUST follow the normative security requirements" in its security considerations page. That page covers audience binding, token theft, HTTPS, PKCE, mix-up, open redirection, Client ID Metadata Document security and the confused deputy problem. The best practices page adds the attack walkthroughs.

Next step

Before your next release, test the five checks in "How to detect it" against your server and client. If you would rather have someone else do it, our MCP development team reviews and builds OAuth flows to the 2026-07-28 spec. More threats are in the MCP Security Center.

Frequently asked questions