Two allowed Protected Resource Metadata discovery mechanisms
MCP servers MUST implement one of two discovery mechanisms for authorization server location: (1) WWW-Authenticate Header — include the resource metadata URL in the `WWW-Authenticate` HTTP header under the `resource_metadata` parameter when returning `401 Unauthorized` responses (RFC9728 Section 5.1); or (2) Well-Known URI — serve metadata at a well-known URI per RFC9728, either at the path of the server's MCP endpoint (e.g. an MCP endpoint at `https://example.com/public/mcp` hosts metadata at `https://example.com/.well-known/oauth-protected-resource/public/mcp`) or at the root `https://example.com/.well-known/oauth-protected-resource`.
Clients MUST support both discovery mechanisms and fall back in order
MCP clients MUST support both Protected Resource Metadata discovery mechanisms: they MUST use the resource metadata URL from the parsed `WWW-Authenticate` header when present; otherwise they MUST fall back to constructing and requesting the well-known URIs, trying the MCP-endpoint-path form (`/.well-known/oauth-protected-resource/<path>`) before the root form (`/.well-known/oauth-protected-resource`).
Client selects among multiple authorization_servers entries
A Protected Resource Metadata document can list multiple authorization servers. Responsibility for selecting which authorization server to use lies with the MCP client, following RFC9728 Section 7.6 'Authorization Servers'.
Clients MUST parse WWW-Authenticate and handle HTTP 401
MCP clients MUST be able to parse `WWW-Authenticate` headers and respond appropriately to `HTTP 401 Unauthorized` responses from the MCP server.
scope parameter in WWW-Authenticate challenge
Servers can also include a `scope` parameter in the `WWW-Authenticate` challenge to indicate the scopes required for accessing the resource; scope semantics and associated client behaviour are defined in the Scope Selection Strategy section of the authorization specification. This is optional, not a MUST.
MCP uses the default oauth-authorization-server well-known suffix
MCP uses the default `oauth-authorization-server` well-known URI suffix defined in RFC 8414 Section 3.1 for authorization server metadata discovery. MCP does not define an application-specific well-known URI suffix.
AS metadata discovery order for issuer URLs with a path
For issuer URLs with path components (e.g. `https://auth.example.com/tenant1`), MCP clients MUST try endpoints in this priority order: 1) OAuth 2.0 Authorization Server Metadata with path insertion: `https://auth.example.com/.well-known/oauth-authorization-server/tenant1`; 2) OpenID Connect Discovery 1.0 with path insertion: `https://auth.example.com/.well-known/openid-configuration/tenant1`; 3) OpenID Connect Discovery 1.0 path appending: `https://auth.example.com/tenant1/.well-known/openid-configuration`.
AS metadata discovery order for issuer URLs without a path
For issuer URLs without path components (e.g. `https://auth.example.com`), MCP clients MUST try: 1) `https://auth.example.com/.well-known/oauth-authorization-server` (OAuth 2.0 Authorization Server Metadata); 2) `https://auth.example.com/.well-known/openid-configuration` (OpenID Connect Discovery 1.0).
MCP servers MUST implement RFC9728 Protected Resource Metadata
MCP servers MUST implement the OAuth 2.0 Protected Resource Metadata specification (RFC9728) to indicate the locations of their authorization servers. The Protected Resource Metadata document returned by the MCP server MUST include the `authorization_servers` field containing at least one authorization server.
Authorization discovery sequence flow
Example authorization discovery flow: the client sends an MCP request without a token; the MCP server (resource server) responds HTTP 401 Unauthorized, possibly with a WWW-Authenticate header. If the header includes `resource_metadata`, the client GETs that URI to obtain resource metadata with the authorization server URL. Otherwise the client probes `GET /.well-known/oauth-protected-resource/mcp` and then `GET /.well-known/oauth-protected-resource`; if neither is found it aborts or uses pre-configured values. The client then validates the resource-server metadata, builds the authorization-server metadata URL, tries the OAuth 2.0 and OpenID Connect discovery endpoints in priority order, performs the OAuth 2.1 authorization flow, exchanges a token request for an access token, and repeats the MCP request with the access token.
Separate client registration state per authorization server
When multiple authorization servers are listed in `authorization_servers`, each is an independent OAuth 2.0 authorization server. Consistent with RFC 6749 Section 2.2, client identifiers are unique to the authorization server that issued them. Clients MUST maintain separate registration state (client credentials, tokens) per authorization server and MUST NOT assume credentials valid for one authorization server will be accepted by another.
CIMD client IDs are portable across authorization servers
Client IDs based on Client ID Metadata Documents are portable across authorization servers because they are self-hosted HTTPS URLs resolved by the authorization server on demand; no re-registration is needed when the authorization server changes.
Client credentials MUST be bound to the issuing authorization server
Clients that use pre-registered credentials, or that persist credentials obtained via Dynamic Client Registration, MUST associate those credentials with the specific authorization server that issued them, keyed by the authorization server's `issuer` identifier. When the authorization server changes (detected via updated protected resource metadata), clients MUST NOT reuse client credentials from a different authorization server and MUST re-register with the new authorization server. If the authorization server indicated by protected resource metadata no longer matches the one the credentials were registered with, clients SHOULD surface an error rather than silently using mismatched credentials.
Three MCP client registration mechanisms and priority order
The MCP specification (2026-07-28) defines three client registration mechanisms: Client ID Metadata Documents (for client and server with no prior relationship, most common), Pre-registration (existing relationship), and Dynamic Client Registration (backwards compatibility). Clients supporting all options SHOULD use this priority order: (1) pre-registered client information if available, (2) Client ID Metadata Documents if the Authorization Server advertises `client_id_metadata_document_supported` in OAuth Authorization Server Metadata, (3) Dynamic Client Registration as fallback if the Authorization Server exposes a `registration_endpoint`, (4) prompt the user to enter client information if no other option is available.
Client ID Metadata Documents SHOULD be supported
MCP clients and authorization servers SHOULD support OAuth Client ID Metadata Documents as specified in draft-ietf-oauth-client-id-metadata-document-00 for client registration. This lets clients use HTTPS URLs as client identifiers where the URL points to a JSON document containing client metadata, addressing the scenario where MCP servers and clients have no pre-existing relationship.
CIMD MUST requirements for MCP clients
MCP clients supporting Client ID Metadata Documents MUST host their metadata document at an HTTPS URL following RFC requirements; the `client_id` URL MUST use the "https" scheme and contain a path component (e.g. https://example.com/client.json); the metadata document MUST include at least `client_id`, `client_name`, and `redirect_uris`; and clients MUST ensure the `client_id` value inside the metadata matches the document URL exactly. Clients MAY use `private_key_jwt` for client authentication (e.g. at the token endpoint) with appropriate JWKS configuration.
CIMD requirements for authorization servers
Authorization servers handling Client ID Metadata Documents SHOULD fetch metadata documents when encountering URL-formatted client_ids; MUST validate that the fetched document's `client_id` matches the URL exactly; SHOULD cache metadata respecting HTTP cache headers; MUST validate redirect URIs presented in an authorization request against those in the metadata document; MUST validate that the document structure is valid JSON and contains required fields; and SHOULD follow the security considerations of the Client ID Metadata Document draft (Section 6) and the MCP Client ID Metadata Document Security section.
Example Client ID Metadata Document JSON
An example CIMD JSON document is: {"client_id": "https://app.example.com/oauth/client-metadata.json", "client_name": "Example MCP Client", "client_uri": "https://app.example.com", "logo_uri": "https://app.example.com/logo.png", "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"}.
CIMD authorization flow and validation steps
In the Client ID Metadata Documents flow: the user initiates a connection; the MCP client sends an authorization request with client_id set to its hosted metadata URL and a redirect_uri such as http://localhost:3000/callback; the authorization server authenticates the user, detects the URL-formatted client_id, performs a GET on the metadata URL, and validates (1) client_id matches the URL, (2) redirect_uri is in the allowed list, (3) document structure is valid, and optionally (4) the domain is allowed via trust policy. On success it shows a consent page using client_name, returns an authorization code via redirect_uri, and exchanges the code for an access token using the same URL client_id. On validation failure it returns an error response with error=invalid_client or invalid_request. The server caches metadata for future requests respecting HTTP cache headers.
Pre-registration support for static client credentials
MCP clients SHOULD support an option for static client credentials such as those supplied by a pre-registration flow. This can be done either by hardcoding a client ID (and client credentials if applicable) for use with that specific authorization server, or by presenting a UI where users enter these details after registering an OAuth client themselves (for example through a configuration interface hosted by the server).
Dynamic Client Registration is deprecated in MCP 2026-07-28
Dynamic Client Registration is deprecated in the 2026-07-28 MCP authorization spec; new implementations should use Client ID Metadata Documents instead. It remains available only for backwards compatibility with authorization servers that do not support Client ID Metadata Documents. MCP clients and authorization servers MAY support OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) to obtain OAuth client IDs without user interaction.
application_type MUST be specified during Dynamic Client Registration
MCP clients MUST specify an appropriate `application_type` during Dynamic Client Registration. Omitting it defaults to "web" under OpenID Connect, which can conflict with native-style redirect URIs; non-OIDC servers safely ignore the parameter. Native applications (desktop apps, mobile apps, CLI tools, and locally-hosted web applications accessed via localhost) SHOULD use application_type: "native"; web applications (remote browser-based apps served from a non-local host) SHOULD use application_type: "web".
Handling DCR registration failures from redirect URI constraints
MCP clients MUST be prepared to handle Dynamic Client Registration failures caused by redirect URI constraints when authorization servers implement OIDC. When a registration request is rejected, clients SHOULD surface a meaningful error to the user or developer, and MAY retry registration with an adjusted `application_type` or with redirect URIs conforming to the authorization server's requirements for that application type.
No URI normalization when comparing iss
After decoding the `iss` value from the application/x-www-form-urlencoded authorization response, clients MUST NOT apply scheme or host case folding, default-port elision, trailing-slash changes, or percent-encoding normalization (RFC 3986 Sections 6.2.2-6.2.3) before comparison. The iss validation applies equally to error responses: on mismatch the client MUST NOT act on or display `error`, `error_description`, or `error_uri`.
Core MUST requirements for authorization servers and MCP servers
Authorization servers MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients. MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728), and MCP clients MUST use it for authorization server discovery. MCP authorization servers MUST provide at least one of OAuth 2.0 Authorization Server Metadata (RFC8414) or OpenID Connect Discovery 1.0, and MCP clients MUST support both discovery mechanisms.
Authorization is OPTIONAL and transport-scoped
MCP authorization is OPTIONAL. When supported: implementations using an HTTP-based transport SHOULD conform to the MCP authorization specification; implementations using STDIO transport SHOULD NOT follow it and instead retrieve credentials from the environment; implementations using alternative transports MUST follow established security best practices for their protocol.
OAuth roles: MCP server = resource server, client = OAuth client
A protected MCP server acts as an OAuth 2.1 resource server accepting protected resource requests with access tokens. An MCP client acts as an OAuth 2.1 client making requests on behalf of a resource owner. The authorization server issues access tokens and may be hosted with the resource server or be a separate entity; its implementation is out of scope.
Client ID Metadata Documents SHOULD, Dynamic Client Registration MAY (deprecated)
Authorization servers and MCP clients SHOULD support OAuth Client ID Metadata Documents (draft-ietf-oauth-client-id-metadata-document-00). They MAY support OAuth 2.0 Dynamic Client Registration (RFC7591), which is deprecated and retained only for backwards compatibility with authorization servers that do not support Client ID Metadata Documents. Before starting the authorization flow, MCP clients MUST obtain a client ID through one of three mechanisms: Client ID Metadata Documents, pre-registration, or Dynamic Client Registration.
Standards the MCP authorization spec is based on
MCP authorization builds on OAuth 2.1 (draft-ietf-oauth-v2-1-13), OAuth 2.0 Bearer Token Usage (RFC6750), Authorization Server Metadata (RFC8414), Dynamic Client Registration (RFC7591), Resource Indicators (RFC8707), Protected Resource Metadata (RFC9728), Authorization Server Issuer Identification (RFC9207), OAuth Client ID Metadata Documents draft-00, OpenID Connect Discovery 1.0, and OpenID Connect Dynamic Client Registration 1.0.
WWW-Authenticate scope parameter and scope selection priority
MCP servers SHOULD include a `scope` parameter in the `WWW-Authenticate` header (RFC 6750 Section 3) indicating required scopes. Clients MUST NOT assume any set relationship between challenged scopes and `scopes_supported` (they may be a subset, superset, or unrelated), and MUST treat challenge scopes as authoritative for the current operation. Client scope selection priority during initial authorization: (1) use the `scope` parameter from the 401 `WWW-Authenticate` header if provided; (2) otherwise use all scopes from `scopes_supported` in the Protected Resource Metadata, omitting the `scope` parameter if `scopes_supported` is undefined.
Example 401 Unauthorized response with resource_metadata and scope
A 401 challenge example: `HTTP/1.1 401 Unauthorized` with header `WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read"`.
Authorization flow step order (401 -> PRM -> AS metadata -> registration -> PKCE -> token)
The complete MCP authorization flow: client sends MCP request without token; server returns HTTP 401 with WWW-Authenticate; client extracts resource_metadata URL; client requests Protected Resource Metadata and parses authorization server(s); client GETs authorization server metadata (trying OAuth 2.0 and OpenID Connect discovery endpoints in priority order); client obtains a client_id via Client ID Metadata Document URL, POST /register dynamic registration, or pre-registration; client generates PKCE parameters, includes the resource parameter, applies scope selection, and records the expected issuer; browser performs the authorization request; authorization server redirects to callback with authorization code and `iss`; client validates `iss` (RFC 9207); client exchanges code plus code_verifier and resource at the token endpoint for an access token (and optional refresh token); client then sends MCP requests with the access token.
iss parameter recording and RFC 9207 validation table
Before redirecting the user-agent, the client MUST record the `issuer` value from the selected authorization server's validated metadata and associate it with the same per-request record holding the PKCE code verifier (and `state`). MCP authorization servers SHOULD include the `iss` parameter in authorization responses including error responses; servers that do MUST advertise `authorization_response_iss_parameter_supported: true` in metadata. Client actions: if the flag is true and `iss` is present, compare to the recorded issuer using simple string comparison (RFC3986 6.2.1); if true and `iss` is absent, reject the response; if the flag is false or absent and `iss` is present, still compare to the recorded issuer; if false/absent and `iss` absent, proceed.
Canonical MCP server URI: valid and invalid examples
Valid canonical MCP server URIs include `https://mcp.example.com/mcp`, `https://mcp.example.com`, `https://mcp.example.com:8443`, and `https://mcp.example.com/server/mcp`. Invalid examples: `mcp.example.com` (missing scheme) and `https://mcp.example.com#fragment` (contains a fragment). Clients SHOULD provide the most specific URI possible; the canonical form uses lowercase scheme and host, but implementations SHOULD accept uppercase scheme/host for robustness, and SHOULD consistently omit a trailing slash.
Bearer token usage: Authorization header on every request, never in query string
MCP clients MUST use the HTTP `Authorization: Bearer <access-token>` request header (OAuth 2.1 Section 5.1.1), and authorization MUST be included in every HTTP request from client to server. Access tokens MUST NOT be included in the URI query string. Example: `GET /mcp HTTP/1.1` with `Host: mcp.example.com` and `Authorization: Bearer eyJhbGciOiJIUzI1NiIs...`.
Token validation and audience binding MUSTs
MCP servers, as OAuth 2.1 resource servers, MUST validate access tokens per OAuth 2.1 Section 5.2 and MUST validate that tokens were issued specifically for them as the intended audience (RFC 8707 Section 2). If validation fails they MUST respond per OAuth 2.1 Section 5.3, and invalid or expired tokens MUST receive an HTTP 401 response. MCP clients MUST NOT send tokens other than those issued by the MCP server's authorization server. MCP servers MUST only accept tokens valid for their own resources and MUST NOT accept or transit any other tokens.
Refresh token requirements for clients and servers
MCP clients that want refresh tokens MUST keep them confidential in transit and storage (OAuth 2.1 Section 4.3), SHOULD include `refresh_token` in their `grant_types` client metadata, MAY add `offline_access` to the `scope` parameter of authorization and token requests when the authorization server metadata lists it in `scopes_supported`, and MUST NOT assume refresh tokens will be issued since the AS retains discretion. MCP servers (protected resources) SHOULD NOT include `offline_access` in the `WWW-Authenticate` scope or in Protected Resource Metadata `scopes_supported`.
Authorization HTTP status codes: 401, 403, 400
Servers MUST return appropriate HTTP status codes for authorization errors: 401 Unauthorized when authorization is required or the token is invalid; 403 Forbidden for invalid scopes or insufficient permissions; 400 Bad Request for a malformed authorization request.
insufficient_scope 403 challenge format
When a request uses a token with insufficient scope at runtime, the server SHOULD respond with HTTP 403 Forbidden (RFC 6750 Section 3.1) and a `WWW-Authenticate` header using the Bearer scheme with parameters: `error="insufficient_scope"`, `scope="required_scope1 required_scope2"` listing minimum needed scopes, `resource_metadata` giving the Protected Resource Metadata URI, and optionally `error_description`. Example: `HTTP/1.1 403 Forbidden` with `WWW-Authenticate: Bearer error="insufficient_scope", scope="files:write", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", error_description="File write permission required for this operation"`.
Step-up authorization flow and scope union requirement
On scope errors (initial authorization or runtime `insufficient_scope`), clients SHOULD request a new token with increased scopes via step-up authorization; clients acting on behalf of a user SHOULD attempt it, while client_credentials clients MAY attempt it or abort immediately. Steps: (1) parse error information from the AS response or WWW-Authenticate header; (2) determine required scopes as the union of the client's previously requested scope set and the current challenge's scopes; (3) initiate (re-)authorization with that scope set; (4) retry the original request no more than a few times, then treat it as a permanent authorization failure. Clients SHOULD implement retry limits and track scope upgrade attempts. Servers MUST account for scope hierarchies, where a broader scope implies narrower ones, when deciding whether a token is sufficient.
Servers should emit all required scopes in a single challenge
Servers SHOULD include all scopes required for the current operation in a single WWW-Authenticate challenge rather than challenging incrementally (returning one missing scope, then another), because incremental challenges force multiple authorization round-trips and degrade user experience. Servers are not required to include the client's previously granted scopes, SHOULD be consistent in their scope-inclusion strategy, and SHOULD consider user experience impact. Scope accumulation across operations is a client-side responsibility.
scopes_supported is the minimal basic-functionality scope set
The `scopes_supported` field in Protected Resource Metadata is intended to represent the minimal set of scopes necessary for basic functionality, with additional scopes requested incrementally through the step-up authorization flow. Servers are not required to surface every dynamically issued scope through `scopes_supported`, but SHOULD strive for consistency in how they construct scope sets.
MCP authorization extensions are optional, additive, composable, independently versioned
Authorization extensions to the core MCP protocol are Optional (implementations may choose to adopt them), Additive (they do not modify or break core protocol functionality), Composable (modular and usable together without conflicts), and Versioned independently (they follow the core MCP versioning cycle but may adopt independent versioning). Supported extensions are listed in the modelcontextprotocol/ext-auth repository.
MCP clients MUST send resource parameter (RFC 8707)
MCP clients MUST include the `resource` parameter, as defined in RFC 8707 Resource Indicators for OAuth 2.0, in both authorization requests and token requests, explicitly specifying the target MCP server resource. This aligns with RFC 9728 Section 7.4 and binds access tokens to their intended resource so they cannot be reused across services.
MCP servers MUST validate token audience before processing requests
MCP servers MUST validate access tokens before processing a request, ensuring the token was issued specifically for that MCP server. Servers MUST only accept tokens intended for themselves and MUST reject tokens that do not include them in the audience claim (or otherwise verify they are the intended recipient). Servers MUST follow OAuth 2.1 Section 5.2 guidelines for validating inbound tokens.
PKCE with S256 is mandatory for MCP clients
MCP clients MUST implement PKCE according to OAuth 2.1 Section 7.5.2 and MUST verify PKCE support before proceeding with authorization. Clients MUST use the `S256` code challenge method when technically capable, as required by OAuth 2.1 Section 4.1.1.
code_challenge_methods_supported discovery requirement
Because OAuth 2.1 and PKCE define no PKCE discovery mechanism, MCP clients MUST rely on authorization server metadata: if `code_challenge_methods_supported` is absent from OAuth 2.0 Authorization Server Metadata, the server does not support PKCE and the client MUST refuse to proceed. For OpenID Connect Discovery 1.0, clients MUST verify the presence of `code_challenge_methods_supported` in provider metadata and MUST refuse to proceed if absent. Authorization servers providing OpenID Connect Discovery 1.0 MUST include `code_challenge_methods_supported` for MCP compatibility.
Redirect URI registration and state parameter rules
MCP clients MUST have redirect URIs registered with the authorization server, and authorization servers MUST validate exact redirect URIs against pre-registered values. MCP clients SHOULD use and verify `state` parameters in the authorization code flow and discard results missing or mismatching the original state. Authorization servers MUST take precautions against redirecting user agents to untrusted URIs (OAuth 2.1 Section 7.12.2) and SHOULD only auto-redirect when the redirection URI is trusted, otherwise MAY inform the user and rely on their decision.
Client ID Metadata Document security: localhost and SSRF
Authorization servers implementing Client ID Metadata Documents MUST consider the security implications of OAuth Client ID Metadata Document Section 6. Servers fetching metadata documents SHOULD consider Server-Side Request Forgery (SSRF) risks. Because Client ID Metadata Documents cannot prevent `localhost` URL impersonation, authorization servers SHOULD display additional warnings for localhost-only redirect URIs, MAY require additional attestation mechanisms, and MUST clearly display the redirect URI hostname during authorization. Servers MAY implement domain-based trust policies for accepting these documents.
OAuth 2.1 security best practices are mandatory
Implementers of MCP clients and servers MUST consider the documented authorization security requirements and MUST follow OAuth 2.1 security best practices as outlined in OAuth 2.1 Section 7 'Security Considerations'.
URL mode elicitation must not be used for MCP authorization itself
URL mode elicitation is not for authorizing the MCP client's access to the MCP server (that is MCP authorization); MCP servers MUST NOT rely on URL mode elicitation to authorize users for themselves. The MCP client's bearer token remains unchanged, and the client's only responsibility is to give the user context about the URL. The MCP server MUST NOT transmit credentials obtained through URL mode elicitation to the MCP client.
Third-party authorization security requirements via URL elicitation
When an MCP server acts as an OAuth client to a third-party service via URL mode elicitation: third-party credentials MUST NOT transit through the MCP client; the MCP server MUST NOT use the client's credentials for the third-party service (that is forbidden token passthrough); the user MUST authorize the MCP server directly, outside the MCP protocol; and the MCP server is responsible for storing and managing the third-party tokens (it must be stateful).