Authorization specification based on OAuth 2.1
MCP authorization is specified using OAuth 2.1, RFC 9728 Protected Resource Metadata, RFC 7591 Dynamic Client Registration, and Client ID Metadata Documents.
MCP · Building servers and clients · all subjects
security
154 notes in this subject, read out of this brain and free to use. This is page 3 of 3.
Enterprise identity integration considerations for MCP
When connecting MCP servers to enterprise IdPs (such as Okta, Entra ID, Ping, Keycloak), implementers must address SSO, tenant isolation, and admin consent flows. These are documented as key friction points.
Credentials for non-HTTP MCP transports
Authorization patterns are needed for stdio, WebSocket, and future transports where the HTTP authorization spec does not directly apply. This is an active area of investigation for how credentials should be carried in non-HTTP transports.
Tool scopes and fine-grained authorization in MCP
Two active working groups address authorization granularity. Tool Scopes WG focuses on per-tool OAuth scope advertisement, step-up authorization, scope challenge, and client-side scope accumulation within the OAuth scope-string model. Fine-Grained Authorization WG addresses authorization granularity beyond scope strings using Rich Authorization Requests (RFC 9396), remediation hints, and multi-credential handling.
Delegated and agentic access patterns in MCP
Use cases for delegated and agentic access include on-behalf-of token exchange, downstream resource access, audience restriction, and consent when an MCP client acts through chains of agents or tools.
Out of scope for MCP Authorization IG: end-user authentication
Authentication of end users to MCP clients (how a host application authenticates its own users) is a host concern, not a protocol concern, and is explicitly out of scope for the Authorization Interest Group.
Out of scope for MCP Authorization IG: transport security
Transport security including TLS, mTLS, and certificate handling is out of scope for the Authorization IG and belongs to the Transports WG.
Authorization attack surfaces being catalogued
Authorization-related attack surfaces being catalogued for Security Best Practices documentation include token confusion, confused-deputy attacks, audience mismatch, and redirect handling.
Related groups for MCP authorization coordination
Authorization work intersects with multiple groups: Enterprise-Managed Authorization IG coordinates IdP, client, and server interoperability testing; Transports WG handles authorization changes at the transport level; Agents WG addresses delegated/on-behalf-of access and multi-agent chain consent; Server Card WG and Registry coordinate client and server identity and discovery; SDK Maintainers coordinate auth client implementations across SDKs.
MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC9728)
MCP servers MUST implement the OAuth 2.0 Protected Resource Metadata specification (RFC9728) to indicate the locations of authorization servers. The Protected Resource Metadata document returned by the MCP server MUST include the authorization_servers field containing at least one authorization server.
Protected Resource Metadata discovery mechanisms
MCP servers MUST implement one of two discovery mechanisms: (1) WWW-Authenticate Header: Include the resource metadata URL in the WWW-Authenticate HTTP header under resource_metadata when returning 401 Unauthorized responses. (2) Well-Known URI: Serve metadata at a well-known URI. For an MCP endpoint like https://example.com/public/mcp, metadata can be at https://example.com/.well-known/oauth-protected-resource/public/mcp or at the root https://example.com/.well-known/oauth-protected-resource.
Client handling of 401 Unauthorized with scope parameter
MCP clients MUST be able to parse WWW-Authenticate headers and respond appropriately to HTTP 401 Unauthorized responses from the MCP server. Servers can include a scope parameter in the WWW-Authenticate challenge to indicate the scopes required for accessing the resource.
Multiple authorization servers and credential separation
When multiple authorization servers are listed in authorization_servers, each is an independent OAuth 2.0 authorization server. 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 that credentials valid for one authorization server will be accepted by another.
Authorization server metadata discovery endpoints for issuer URLs without path components
For issuer URLs without path components (e.g., https://auth.example.com), MCP clients MUST try endpoints in this priority order: (1) OAuth 2.0 Authorization Server Metadata: https://auth.example.com/.well-known/oauth-authorization-server (2) OpenID Connect Discovery 1.0: https://auth.example.com/.well-known/openid-configuration
Authorization server metadata validation requirement
After retrieving an authorization server metadata document, MCP clients MUST validate it as required by RFC8414 Section 3.3 or OpenID Connect Discovery Section 4.3. The issuer value in the document MUST be identical to the issuer identifier used to construct the well-known URL. If they differ, the client MUST NOT use the metadata. For example, a document fetched from https://attacker.example/.well-known/oauth-authorization-server containing issuer: https://honest.example MUST be rejected.
MCP uses default oauth-authorization-server well-known URI 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.
OAuth 2.0 Protected Resource Metadata discovery flow
Clients MUST interpret the WWW-Authenticate header and fallback to probing for metadata if not present. Servers SHOULD return the WWW-Authenticate header. The client flow is: attempt the MCP request without a token; if receiving HTTP 401 Unauthorized, check for a WWW-Authenticate header with resource_metadata parameter and use it to locate resource metadata; if the header is absent or does not include resource_metadata, fallback to requesting /.well-known/oauth-protected-resource.
OAuth 2.0 metadata discovery fallback locations
Clients should attempt to discover OAuth 2.0 protected resource metadata using two mechanisms in order: first from the resource_metadata parameter in the WWW-Authenticate header returned with a 401 Unauthorized response, and second from the well-known endpoint /.well-known/oauth-protected-resource if the header is absent or does not include the parameter.
Fallback to .well-known endpoint for OAuth metadata
When an MCP client does not receive a WWW-Authenticate header with resource_metadata on a 401 response, it must fallback to requesting /.well-known/oauth-protected-resource to obtain the resource metadata. If metadata is not found at this location, the client may abort or use pre-configured values.
RFC 9728 alignment for OAuth 2.0 Protected Resource Metadata
MCP SEP-985 aligns the protocol's handling of OAuth 2.0 Protected Resource Metadata with RFC 9728. The specification now allows servers to use either a WWW-Authenticate header or metadata discovery via a well-known URL, whereas previously it required the header. RFC 9728 Section 5 states that a protected resource MAY use the WWW-Authenticate HTTP response header field to return a URL to its protected resource metadata, allowing flexibility in deployment models.
SHOULD vs MAY for WWW-Authenticate header in OAuth metadata discovery
The MCP spec requires servers to return a WWW-Authenticate header with SHOULD (not MAY as RFC 9728 suggests) to enable supporting other features such as incremental authorization, where a request for a tool may receive a 401 response with a WWW-Authenticate challenge indicating additional required scopes.
OAuth 2.0 authorization flow with fallback metadata discovery
After discovering OAuth 2.0 protected resource metadata via either the WWW-Authenticate header or the .well-known endpoint, the client must validate the resource server metadata and build the authorization server metadata URL. The client then requests /.well-known/oauth-authorization-server from the authorization server to obtain authorization server metadata, followed by performing the OAuth 2.1 authorization flow and token request, before making authenticated MCP requests with the access token.
OAuth 2.0 metadata discovery: WWW-Authenticate header or .well-known fallback
Clients MUST interpret the WWW-Authenticate header when present. If a 401 Unauthorized response includes a WWW-Authenticate header with a resource_metadata parameter, clients extract the resource_metadata URL from that header and use it to fetch the protected resource metadata. If the header is absent or does not include resource_metadata, clients fall back to requesting /.well-known/oauth-protected-resource to locate the resource metadata.
OAuth 2.0 server metadata emission recommendation
Servers SHOULD return the WWW-Authenticate header in 401 Unauthorized responses, including the resource_metadata parameter. This is stronger than RFC 9728's MAY recommendation because it enables incremental authorization and reduces client complexity, though servers may omit the header if feasible for their deployment model.
OAuth 2.0 metadata discovery flow for MCP clients
The client first attempts an MCP request without a token. Upon receiving HTTP 401 Unauthorized, it checks for a WWW-Authenticate header containing resource_metadata. If present, it extracts the metadata URL from the header. If absent, it probes /.well-known/oauth-protected-resource. Once resource metadata is obtained (containing the authorization server URL), the client fetches /.well-known/oauth-authorization-server from the authorization server to obtain authorization server metadata. It then performs the OAuth 2.1 authorization flow, obtains an access token, and retries the MCP request with the token.
When to use .well-known metadata discovery instead of WWW-Authenticate
In large-scale, dynamic, multi-tenant environments with centralized authentication services separate from backend resource servers, injecting WWW-Authenticate headers from backend services can be complex due to separation of concerns and infrastructure overhead. In these cases, servers may rely on .well-known metadata endpoint discovery instead, reducing communication overhead between components and simplifying deployment in distributed environments.
Client fallback logic for OAuth metadata discovery
Clients implementing OAuth 2.0 protected resource support must implement logic to probe metadata endpoints as a fallback. When the WWW-Authenticate header is absent or lacks resource_metadata, clients must attempt to fetch /.well-known/oauth-protected-resource. This increases client complexity compared to header-only implementations but enables broader server deployment flexibility.
Incremental authorization support in OAuth 2.0 metadata flow
By using the WWW-Authenticate header in 401 responses, servers can indicate when additional OAuth scopes are needed. For example, when a client makes a tool request but requires additional scopes, the server responds with 401 and includes a WWW-Authenticate challenge indicating the required scopes, enabling incremental authorization flows.
MCP 2026-07-28 requires iss parameter validation in authorization responses
Clients must now validate the iss parameter on authorization responses per RFC 9207 (SEP-2468) in MCP 2026-07-28. This is a mitigation for mix-up attacks more prevalent in MCP's single-client, many-server deployment pattern. In a future version, clients will be expected to reject responses that omit iss, so authorization servers should begin supplying it now.
OpenID Connect application_type in Dynamic Client Registration
Clients now declare their OpenID Connect application_type during Dynamic Client Registration (SEP-837) in MCP 2026-07-28, avoiding the common case where an authorization server defaults a desktop or CLI client to 'web' and rejects its localhost redirect URI.
OAuth credentials binding to issuer in MCP 2026-07-28
Clients bind registered credentials to the issuing authorization server's issuer and re-register when a resource migrates between authorization servers (SEP-2352) in MCP 2026-07-28.
MCP 2026-07-28 refresh token request from OpenID Connect
MCP 2026-07-28 specifies how to request refresh tokens from OpenID Connect-style authorization servers (SEP-2207).
Scope accumulation during step-up in MCP 2026-07-28
MCP 2026-07-28 clarifies scope accumulation during step-up (SEP-2350) in authorization flows.
Discovery suffix documentation in MCP 2026-07-28
MCP 2026-07-28 clarifies the .well-known discovery suffix usage (SEP-2351).