authorization_servers
field containing at least one authorization server.
The specific use of authorization_servers
is beyond the scope of this specification; implementers should consult
OAuth 2.0 Protected Resource Metadata (RFC9728) for
guidance on implementation details.
Implementors should note that Protected Resource Metadata documents can define multiple authorization servers. The responsibility for selecting which authorization server to use lies with the MCP client, following the guidelines specified in
RFC9728 Section 7.6 “Authorization Servers”.
MCP servers MUST use the HTTP header WWW-Authenticate
when returning a 401 Unauthorized to indicate the location of the resource server metadata URL
as described in RFC9728 Section 5.1 “WWW-Authenticate Response”.
MCP clients MUST be able to parse WWW-Authenticate
headers and respond appropriately to HTTP 401 Unauthorized
responses from the MCP server.
resource
parameter:
resource
parameter in
RFC 9728.
MCP clients SHOULD provide the most specific URI that they can for the MCP server they intend to access, following the guidance in RFC 8707. While the canonical form uses lowercase scheme and host components, implementations SHOULD accept uppercase scheme and host components for robustness and interoperability.
Examples of valid canonical URIs:
https://mcp.example.com/mcp
https://mcp.example.com
https://mcp.example.com:8443
https://mcp.example.com/server/mcp
(when path component is necessary to identify individual MCP server)mcp.example.com
(missing scheme)https://mcp.example.com#fragment
(contains fragment)Note: While bothFor example, if accessing an MCP server athttps://mcp.example.com/
(with trailing slash) andhttps://mcp.example.com
(without trailing slash) are technically valid absolute URIs according to RFC 3986, implementations SHOULD consistently use the form without the trailing slash for better interoperability unless the trailing slash is semantically significant for the specific resource.
https://mcp.example.com
, the authorization request would include:
Status Code | Description | Usage |
---|---|---|
401 | Unauthorized | Authorization required or token invalid |
403 | Forbidden | Invalid scopes or insufficient permissions |
400 | Bad Request | Malformed authorization request |
resource
parameter in authorization and token requests as specified in the Resource Parameter Implementation sectionlocalhost
or use HTTPS.resource
parameter as defined in RFC 8707 - Resource Indicators for OAuth 2.0
to explicitly specify the target resource for which the token is being requested. This requirement aligns with the recommendation in
RFC 9728 Section 7.4. This ensures that access tokens are bound to their intended resources and
cannot be misused across different services.