[Auth] OAuth flow does not support `resourceMetadataUrl`

[shays10]

Describe the bug
Starting from version 13.0.1, typescript-sdk supports resourceMetadataUrl. This feature enables MCP Servers to include a specific resourceMetadataUrl in the WWW-Authenticate header when returning a 401 response to the MCP Client.

In such cases, the MCP Client is expected to invoke the SDK's auth method with the provided resourceMetadataUrl, which overrides the default /.well-known/oauth-protected-resource location.

However, it appears the current behavior deviates from this specification:

1. The auth invocation here does not include the resourceMetadataUrl.

2. Additionally, the Guided OAuth flow omits it in this step.

To Reproduce
Steps to reproduce the behavior:
Create an MCP server that returns 401 with a resourceMetadataUrl value as part of the WWW-Authenticate header.

Expected behavior
The MCP client should hit that location, instead of trying to fetch from <serverUrl>/.well-known/oauth-protected-resource

[pcarleton]

👍 thanks for flagging, this is definitely missing.

Ideally we want the guided flow to hit the server URL first, to get the WWW-Authenticate, and only fallback to constructing the metadata URL if it needs to

[lucheng-hugh]

Would like to know when this can be supported. I really like the inspector for testing things, but this becomes a blocking issue when more than one resource is hosted on one host.

[rinormaloku]

Why isn't this being worked on? Is there some need for discussions, or just a matter of adding this feature?

Asking as this seems trivial to be added, and it is important to test MCP Servers.

[pksorensen]

the spec is clean on what it should do: https://modelcontextprotocol.io/specification/draft/basic/authorization#server-metadata-discovery

[pksorensen]

note that @claude desktop or code does not implement it either.

[shays10]

Nor does Cursor btw

[ptc-ccrabb]

@pksorensen This is about getting the protected resource metadata, not getting the authorization server metadata.

Section 5 of RFC9728 allows a protected resource to exactly specify the URL to use for the Protected Resource Metadata document. The Protected Resource Metadata will point the Client to an Authorization Server, at which point the Authorization Server Metadata Discovery algorithm (as you linked above) does apply.

RFC9728 is pretty clear that the first request made should be to the resource itself, which will explain how it is protected. Discovery of protected resource metadata applies only if the resource isn't specific about where the protected resource metadata is.

It would be nice for MCP Inspector to follow the RFCs regardless of what other apps do.

[halllo]

RFC9728 is pretty clear that the first request made should be to the resource itself, which will explain how it is protected.

I absolutely agree.

The first request made should be to the resource itself, which will explain how it is protected. Then it should acquire the protected resource metadata based on the URI from the WWW-Authenticate. This makes so much more sense then having a set of hardcoded rules and trying out different URI permutations.

The MCP auth spec even shows it in this sequence diagram, that the first call is towards the resource (server) and then the second call goes to /.well-known/oauth-protected-resource.

For Authorization Server Metadata the spec made it very clear and even differentiated between path insertion and path appending. I don't understand why they didn't make it as clear for Protected Resource Metadata.