[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

[q815101630]

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.

[cliffhall]

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.

I have a PR where I am trying to sort this. The problem is the WWW-Authenticate header is not making it back to the client, and the 401 Unauthorized is coming back as a 200.

[olaservo]

Hi @cliffhall I tentatively labeled as something to address in v2 but wanted to check whether this one should be left open to fix in the current Inspector.

[cliffhall]

Hi @cliffhall I tentatively labeled as something to address in v2 but wanted to check whether this one should be left open to fix in the current Inspector.

It's pressing, and v2 is a long way off. I think we should do this. Problem is WWW-Authenticate headers emitted from the server aren't making it back to the client via the proxy. I have a PR that gets the header back to the client, but I was holding out to get the error shape sorted, but I guess that's less important than the header. It has a bunch of conflicts to resolve. I could dive back into that.