A client sends its first request to a remote MCP server and receives HTTP 401. How should it locate the authorization server it needs to use?
Select an answer to reveal the explanation.
Short Explanation
The 401 is a signpost, and the WWW-Authenticate header usually tells you exactly where the map is. If it doesn't, you check the well-known spots. That map, the Protected Resource Metadata, names the authorization server, so you never have to guess.
Full Explanation
MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728), and clients must use it for authorization server discovery. Servers provide the metadata location in one of two ways: a resource_metadata URL in the WWW-Authenticate header of a 401 response, or a well-known URI, either at the path of the MCP endpoint, such as /.well-known/oauth-protected-resource/mcp, or at the root, /.well-known/oauth-protected-resource. Clients must support both, must use the header's URL when present, and otherwise must fall back to the well-known URIs in that order. The metadata's authorization_servers field lists at least one authorization server, and the client then fetches that server's metadata through OAuth 2.0 Authorization Server Metadata or OpenID Connect Discovery, trying the defined well-known endpoints in priority order. Calling server/discover fails because DiscoverResult carries versions, capabilities, serverInfo and instructions, not authorization server locations. Guessing paths on the MCP host fails by concept: the authorization server may be a separate entity, and endpoints come from validated metadata, not assumption. Sending a registration request to the MCP endpoint fails because registration happens at the authorization server, after discovery. Exam caveat: validate that the issuer in fetched metadata matches the one used to build its URL. Operational check: trigger a 401 and confirm the client fetches the resource_metadata URL first.