Summary

authorization applies to HTTP-based transports. A protected MCP server acts as an resource server; the MCP client acts as an OAuth client; an authorization server issues access for the MCP server.

Authorization is optional for MCP implementations, but when an HTTP MCP server is protected it should follow the MCP authorization specification. Stdio servers should not use this flow; they should get credentials from the local environment.

MCP client → protected MCP server → protected-resource metadata
     │                    │
     └──── authorization server discovery ──── token issuance

Key pieces:

Protected-resource metadata advertises which authorization server protects the MCP endpoint.
MCP clients must use protected-resource metadata for authorization-server discovery.
Authorization servers and MCP clients should support OAuth Client ID Metadata Documents.
RFC 7591 dynamic client registration is Deprecated in 2026-07-28 in favor of Client ID Metadata Documents; it remains available for backward compatibility.
Access tokens must be sent in the Authorization: Bearer <token> header and must not be placed in URLs.
Tokens must be audience-bound to the MCP server resource.

Transport Scope

MCP authorization is defined for HTTP-based transports.

Use this page for:

Streamable HTTP MCP servers exposed over HTTPS
remote MCP servers that need per-user or per-tenant access control
agent clients that need to discover the right authorization server

Do not use this page as the primary model for stdio MCP servers. Stdio servers normally receive credentials from environment variables, local config, keychains, or the host application.

Relationship to auth.md

MCP authorization and auth.md solve adjacent problems:

MCP authorization describes how an MCP client obtains and presents an access token to a protected HTTP MCP server.
auth.md describes how an agent can register or claim a user-bound credential with a service before making authenticated calls.

Use MCP authorization for the transport-level OAuth flow. Use auth.md only when the service also wants to publish an agent-readable registration path, such as provider-attested registration or an OTP-backed user claim ceremony.

Protected Resource Metadata

A protected MCP server must advertise how clients can discover its authorization server.

The server can do this in two ways:

Return a WWW-Authenticate header with a resource_metadata URL on 401 Unauthorized.
Serve OAuth protected-resource metadata from a .

Common well-known locations include:

https://example.com/.well-known/oauth-protected-resource
https://example.com/.well-known/oauth-protected-resource/public/mcp

The protected-resource metadata should include an authorization_servers field. The MCP client uses that metadata to discover the authorization server and then follows the normal OAuth flow.

Authorization Server Discovery

MCP authorization servers must support at least one discovery mechanism:

OAuth 2.0 Authorization Server Metadata
Discovery 1.0

MCP clients must support both discovery mechanisms. This matters because different issuers publish metadata at different well-known paths.

For an issuer such as https://auth.example.com/tenant1, clients may need to try path-insertion and path-appending forms:

https://auth.example.com/.well-known/oauth-authorization-server/tenant1
https://auth.example.com/.well-known/openid-configuration/tenant1
https://auth.example.com/tenant1/.well-known/openid-configuration

Client Registration

MCP supports three client registration approaches:

Approach	Use when
Pre-registration	The client and authorization server already have a relationship.
OAuth Client ID Metadata Documents	The client and authorization server do not have a prior relationship, and the authorization server supports URL-formatted client IDs.
Dynamic client registration (deprecated)	The authorization server supports RFC 7591 and no better option is available.

When several options exist, clients should prefer pre-registered client details, then Client ID Metadata Documents when supported, then dynamic client registration as a fallback.

Current 2026-07-28 behavior: RFC 7591 dynamic client registration is Deprecated in favor of Client ID Metadata Documents, under the same 12-month minimum deprecation window as the rest of the new lifecycle policy. It keeps working for backward compatibility, but new clients and authorization servers should implement Client ID Metadata Documents instead. Where you must still support DCR, the application_type field becomes required in the registration request (SEP-837).

Client ID Metadata Documents

Client ID Metadata Documents are an OAuth client registration mechanism.

The client uses an HTTPS URL as its client_id. That URL points to a JSON document containing OAuth client metadata. The document must include at least:

client_id
client_name
redirect_uris

Example:

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "redirect_uris": ["http://127.0.0.1:3000/callback", "http://localhost:3000/callback"],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Authorization servers advertise support with:

{
  "client_id_metadata_document_supported": true
}

The authorization server should fetch the metadata document, validate that the document's client_id exactly matches the URL, validate redirect URIs, and cache the document according to HTTP cache headers.

Clients may use private_key_jwt for token endpoint authentication when the metadata document provides the required configuration.

This is already shipping outside the spec text: OpenAI's Apps SDK (2026-08-21) uses a Client ID Metadata Document at https://chatgpt.com/oauth/client.json as ChatGPT's stable client ID, and pairs it with a stable OAuth redirect URL, whenever the authorization server supports RFC 9207 issuer identification. Servers that don't support RFC 9207 fall back to the older per-connector callback behaviour - a concrete illustration of why issuer validation (below) and Client ID Metadata Document support are worth implementing together.

Token Use

MCP clients must send access tokens in the authorization header:

Authorization: Bearer <access-token>

Access tokens must not be placed in URI query strings.

The MCP client must include the OAuth Resource Indicators resource parameter during authorization and token requests. The resource must identify the MCP server the token is intended for.

MCP servers must validate that incoming access tokens were issued for their own resource. They must not accept tokens issued for another resource, and they must not pass through tokens they received from an MCP client.

Scope Challenges

When a request lacks sufficient , the server should use normal OAuth error handling:

401 Unauthorized when authorization is required or the token is invalid
403 Forbidden when the token is valid but lacks required scope
WWW-Authenticate with scope and resource_metadata when the client needs to request additional scope

Clients should treat a challenged scope as authoritative for satisfying that request. They should not assume it is always identical to the full scopes_supported list.

Current 2026-07-28 Requirements

The current 2026-07-28 revision changes this model in six places. None of them break a correctly implemented 2025-11-25 client, but each closes a gap that a loose implementation leaves open.

Issuer validation (SEP-2468) - clients must validate the iss parameter returned on the authorization response against the issuer they discovered, per RFC 9207. This is the defense against a mix-up attack where a malicious authorization server induces a client to redeem a code at the wrong issuer.

Credentials bound to their issuing authorization server (SEP-2352) - client credentials must be stored keyed by issuer, used only with the authorization server that issued them, and re-registered when a server's issuer changes. A credential cached against an MCP server URL rather than an issuer is the bug this closes.

application_type required in dynamic client registration (SEP-837) - where you still support RFC 7591 registration, the request must declare application_type. Registration requests that omit it are no longer well-formed.

Dynamic client registration Deprecated - RFC 7591 registration is Deprecated in favor of Client ID Metadata Documents, as described above.

Sessions removed - there is no connect-time authentication step whose proof a later request could ride on; every request must carry and be validated against its own token, which is what this page already requires.

Mcp-Method and Mcp-Name headers required - Streamable HTTP POSTs must carry both, which gives a gateway or proxy enough information to apply per-method authorization policy without parsing the JSON-RPC body.

MCP Authorization