oauth protected resource metadata URL

[ke-yu]

Question

Suppose we run multiple MCP servers under https://example.com/mcpServers and one MCP server URL is https://example.com/mcpServers/myAwesomeServer, should the protected resource metadata endpoint be https://example.com/.well-known/oauth-protected-resource/mcpServers/myAwesomeServer?

From this code https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/client/auth.py#L206 seems the protected resource metadata URL is always base URL + "/.well-known/oauth-protected-resource".

    async def _discover_protected_resource(self) -> httpx.Request:
        """Build discovery request for protected resource metadata."""
        auth_base_url = self.context.get_authorization_base_url(self.context.server_url)
        url = urljoin(auth_base_url, "/.well-known/oauth-protected-resource")
        return httpx.Request("GET", url, headers={MCP_PROTOCOL_VERSION: LATEST_PROTOCOL_VERSION})

According to https://datatracker.ietf.org/doc/html/rfc9728#name-obtaining-protected-resourc

Protected resources supporting metadata MUST make a JSON document containing metadata as specified in Section 2 available at a URL formed by inserting a well-known URI string into the protected resource's resource identifier between the host component and the path and/or query components, if any. By default, the well-known URI string used is /.well-known/oauth-protected-resource.

So if the resource server URL is https://example.com/mcpServers/myAwesomeServer, the protected resource URL should be https://example.com/.well-known/oauth-protected-resource/mcpServers/myAwesomeServer

Additional Context

No response

[heiko-braun]

I interpret the the Oauth spec the same way and would consider this a bug in the SDK. By the way, it's the same requirement for /.well-known/oauth-authorization-server

[q815101630]

I also agree this is a bug, the RFC 9728 Section 3.1 gave an example of inserting the /.well-known/oauth-protected-resource between the host and resource name

If the resource identifier value contains a path or query component, any terminating slash (/) following the host component MUST be removed before inserting /.well-known/ and the well-known URI path suffix between the host component and the path and/or query components.
The consumer of the metadata would make the following request when the resource identifier is https://resource.example.com/resource1 and the well-known URI path suffix is oauth-protected-resource to obtain the metadata, since the resource identifier contains a path component:
GET /.well-known/oauth-protected-resource/resource1 HTTP/1.1
Host: resource.example.com
Using path components enables supporting multiple resources per host.

@ihrpr sorry to ping you, but this is also another bug that blocks hosting multiple resources on one host

[shulkx]

I have implemented a fix for this: #1407

[felixweinberger]

Closing as #1407 has been merged