OAuth 2.1 for MCP: What the Spec Standardised and What You Need to Know

Before the spec: every server, its own auth

Remote MCP servers before mid-2025 each defined their own auth. Some used static API keys passed in headers. Some used custom JWT flows. A few implemented OAuth 2.0 — and each of those used a different combination of flows, scopes, and token formats. MCP client authors had to implement an "auth model adapter" per server, which scaled poorly and made remote MCPs harder to ship than local stdio servers.

The 2025-06-18 spec replaced that mess with one rule: remote MCP servers MUST support OAuth 2.1 with PKCE for user-facing flows, and SHOULD support dynamic client registration. Clients now implement one flow and it works against every spec-compliant server.

The OAuth 2.1 handshake for MCP

1. 1

   Discovery

   The client fetches the server's OAuth metadata (typically at /.well-known/oauth-authorization-server). This returns the authorization endpoint, token endpoint, registration endpoint, supported scopes, and PKCE methods.

2. 2

   Dynamic client registration

   The client POSTs to the registration endpoint with its name, redirect URI, and the grant types it supports. The server returns a client_id (and optionally a client_secret for confidential clients). This step is skipped if the client is already registered.

3. 3

   Authorization request

   The client generates a PKCE code verifier, derives the challenge, and opens the authorization endpoint in the user's browser with client_id, redirect URI, scope, and PKCE challenge. The user signs in to the upstream service and consents to the scopes.

4. 4

   Token exchange

   The server redirects back to the client with an authorization code. The client POSTs the code plus the PKCE verifier to the token endpoint and receives an access token (and usually a refresh token). The server validates the verifier matches the original challenge before issuing tokens.

5. 5

   Tool calls

   Subsequent JSON-RPC calls to the MCP server include the access token in the Authorization header. Refresh tokens are exchanged when the access token expires, using stricter rotation rules than OAuth 2.0 — each refresh issues a new refresh token, and the old one is invalidated.

Audience binding and the confused-deputy fix

The spec\'s most important security addition is explicit audience binding. Every access token an MCP server issues is bound to that server\'s audience identifier. If a downstream service calls a different MCP using that token, validation fails. This blocks the classic "I have your token, let me reuse it elsewhere" attack — the token is only valid for the audience it was minted for.

For server authors: include the audience claim in every token you issue and verify it on every request. For client authors: do not pass tokens between servers — request a fresh token per MCP via the OAuth flow even if the upstream service is the same.

What you have to implement

Migration path from API keys

If you maintain an MCP server that currently uses API keys, the spec allows you to support both during migration. Keep the API key path for backward compatibility, add the OAuth 2.1 path for new clients, and deprecate the API key path on a published timeline. Most servers complete the transition over one or two release cycles.

The carrot for users: OAuth 2.1 means no more environment-variable token management and no more credential rotation in config files. The carrot for you as a server author: scoped, revocable, audited access by default — the security posture upgrade pays for itself the first time a user accidentally commits a config file.

Frequently asked questions