MCP Authorization: What the Spec Requires

MCP authorization is the part of the specification that controls how an AI app gets permission to use a protected remote MCP server. It is built on OAuth 2.1. The MCP server acts as an OAuth resource server, the AI app acts as an OAuth client, and an authorization server signs the user in and issues access tokens.

Status in the 2026-07-28 spec: optional (authorization itself is optional; when used over HTTP, the rules below apply)

This page lists what the 2026-07-28 authorization specification requires, in the order a developer or reviewer needs it. For a step-by-step walk through the sign-in flow, see our companion guide MCP authentication and OAuth 2.1. Checked on 28 October 2026.

Why MCP has an authorization spec

Remote MCP servers often reach private data and take actions. Without a shared standard, every AI app would need custom sign-in code for every server. The spec picks "a selected subset" of existing OAuth standards "to ensure security and interoperability while maintaining simplicity."

The standards it builds on include the OAuth 2.1 draft, Bearer Token Usage (RFC 6750), Authorization Server Metadata (RFC 8414), Resource Indicators (RFC 8707), Protected Resource Metadata (RFC 9728), issuer identification (RFC 9207), Client ID Metadata Documents, and OpenID Connect Discovery.

Who does what

The spec says the authorization server "may be hosted with the resource server or a separate entity."

The requirements, grouped

Discovery

• MCP servers "MUST implement OAuth 2.0 Protected Resource Metadata." See protected resource metadata.
• Authorization servers must offer RFC 8414 metadata or OpenID Connect Discovery, and clients "MUST support both."

Client registration

Before starting, clients "MUST obtain a client ID" through pre-registration, a Client ID Metadata Document, or Dynamic Client Registration. See Client ID Metadata Documents and Dynamic Client Registration.

The authorization request

The security considerations page sets the core client rules:

• "MCP clients MUST implement PKCE" and use S256 when technically capable.
• If authorization server metadata lacks code_challenge_methods_supported, the client "MUST refuse to proceed."
• The resource parameter "MUST be included in both authorization requests and token requests" and must name the MCP server's canonical URI.
• Before redirecting, the client records the expected issuer. A returned iss must match it before the code is redeemed.

Using tokens

• Tokens go in the Authorization: Bearer header on every HTTP request.
• "Access tokens MUST NOT be included in the URI query string."
• Servers "MUST validate that access tokens were issued specifically for them as the intended audience."
• "MCP servers MUST NOT accept or transit any other tokens." If the server calls an upstream API, it uses a separate token. See why MCP servers must not pass tokens through.

Scopes and errors

Servers "SHOULD" put a scope parameter in the WWW-Authenticate header. This is the spec's example 401 response:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

When a token lacks a scope at runtime, the server "SHOULD" return 403 with error="insufficient_scope" and the needed scopes. Clients then run a step-up flow, requesting the union of earlier and newly required scopes.

The token response the client finally receives is standard OAuth JSON. A typical shape, adapted from the token response in the Enterprise-Managed Authorization spec:

{
  "token_type": "Bearer",
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "expires_in": 86400,
  "scope": "files:read"
}

Token safety

Clients and servers "MUST implement secure token storage." Authorization servers "SHOULD issue short-lived access tokens" and "MUST rotate refresh tokens" for public clients. All authorization server endpoints "MUST be served over HTTPS," and redirect URIs must be localhost or HTTPS.

Extensions

The core spec covers a user approving access interactively. Two official extensions in the ext-auth repository cover other cases: OAuth Client Credentials for machine-to-machine access, and Enterprise-Managed Authorization for company identity providers.

What changed across spec versions

The 2026-07-28 changes come from the 2026-07-28 changelog. The spec also expects a future revision to upgrade authorization servers' iss inclusion "from SHOULD to MUST."

Common mistakes

• Accepting any valid token. Audience checks are mandatory. A token for another service must be rejected.
• Forwarding the user's token upstream. That is token passthrough, and it is forbidden.
• Skipping the resource parameter because the authorization server ignores it. The spec says clients "MUST send this parameter regardless."
• Requesting every scope up front. The spec favors least privilege and step-up.
• Putting tokens in URLs. They leak into logs. Use the header.

More pitfalls are collected in common MCP OAuth misconfigurations.

Next step

The first thing a client fetches is the server's metadata document. Read OAuth Protected Resource Metadata in MCP next, or see how our MCP development team builds and reviews authorization.

Frequently asked questions