MCP Authorization with OAuth 2.1: DCR & PKCE

The big picture

OAuth 2.1 (a tightened version of OAuth 2.0) governs how a client gets a token, and how the server validates it. MCP layers on:

Protected Resource Metadata (RFC 9728, SEP-985) — the server advertises which authorization server to use.
Dynamic Client Registration — clients register on demand.
Client ID Metadata Documents (SEP-991) — URL-based client identity that avoids per-server registration.
OAuth Client Credentials (SEP-1046) — machine-to-machine flows.
Enterprise-Managed Authorization (SEP-990) — IdP-enforced policy controls.

The authorization flow

Client makes an MCP request without a token.
Server responds 401 with a WWW-Authenticate header pointing at Protected Resource Metadata.
Client fetches the metadata, learns the authorization server URL.
Client registers (DCR) or uses a Client ID Metadata Document URL.
Client kicks off the authorization code flow with PKCE; user grants consent.
Client exchanges code for an access token.
Client retries the original MCP request with Authorization: Bearer ….

Client ID Metadata Documents (SEP-991)

Pre-registration doesn't scale: AI clients connect to servers they've never seen. DCR works but requires the auth server to store every client's metadata. MCP's answer is the Client ID Metadata Document: the client's identifier IS a URL that returns its metadata.

No database of registered clients.
Auth server fetches metadata on demand.
Document signing prevents tampering (Client ID Metadata Document Security).

Error responses

Code	Meaning
401	Authorization required or token invalid.
403	Insufficient scopes or permissions.
400	Malformed authorization request.

Local clients = public OAuth 2.1 clients

MCP treats every local client (Claude Desktop, IDE plug-ins) as a public OAuth 2.1 client. That has consequences:

PKCE is mandatory.
Client secrets MUST NOT be embedded in shipped binaries.
Localhost redirect URIs need protection against port collisions and DNS rebinding.

Quick summary

OAuth 2.1 + PKCE is the baseline
Discover the auth server via Protected Resource Metadata (RFC 9728)
Client ID Metadata Documents solve "no pre-existing relationship"
Local clients are public — no embedded secrets, no skipping PKCE

MCP Authorization FAQ

Why does MCP use OAuth 2.1 for authorization?

OAuth 2.1 is a hardened, industry-standard authorization framework. MCP adopted it because remote MCP servers need a secure, interoperable way to grant clients access tokens — without each server inventing its own auth scheme.

What is Dynamic Client Registration (DCR) in MCP?

DCR (RFC 7591) allows MCP clients to register themselves with an authorization server at runtime, without requiring a developer to manually create a client ID beforehand. This is essential when clients encounter a new MCP server they've never seen before.

What are Client ID Metadata Documents in MCP?

Client ID Metadata Documents (SEP-991) allow MCP clients to use a URL as their client identity instead of a server-registered client ID. The authorization server fetches the document from the URL to verify the client's metadata.

How does PKCE improve MCP authorization security?

PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks. MCP authorization requires PKCE for all public clients (those that can't keep a secret, like desktop apps), ensuring tokens can only be exchanged by the original requester.

What is Enterprise-Managed Authorization in MCP?

Enterprise-Managed Authorization (SEP-990) lets organizations use their existing Identity Provider (IdP) — like Okta or Azure AD — to enforce policies on MCP client access. The IdP validates tokens and enforces access controls at the organizational level.