The inspector does not follow the spec according to authorization senarios

[pksorensen]

Using inspector 0.16.2

configured with http-streamable http://localhost:5010/mcp

pressing connect and the following will happen:

HTTP/1.1 POST http://localhost:5010/mcp - 401 0 null 37.009ms with WWW-authenticate: Bearer realm="McpAuth", resource_metadata="http://localhost:5010/.well-known/oauth-protected-resource"

It will attempt to go to: http://localhost:5010/.well-known/oauth-protected-resource/mcp however my understanding is that it should go to http://localhost:5010/.well-known/oauth-protected-resource

After two failed attempt it moves correctly to

HTTP/1.1 GET http://localhost:5010/.well-known/oauth-protected-resource response:

{
  "resource": "http://localhost:5010",
  "authorization_servers": [
    "http://localhost:5010/realms/mcpdash/"
  ],
  "bearer_methods_supported": [
    "header"
  ],
  "scopes_supported": [
    "mcp:booking"
  ],
  "resource_documentation": "https://mcpdash.ai/mcp/booking"
}

then it tries http://localhost:5010/.well-known/oauth-authorization-server/mcp which is not expected, instead it should have used the authorization server defined in the oauth-protected-resource but it does not.

Is it me who have misunderstood this or is it not implemented atm

[mbroton]

It works as described in RFC 9728 which is included in Standard Compliance

Protected resources supporting metadata make a JSON document containing metadata as specifed in Section 2 available at a URL formed by inserting a well-known URI string into the protected resource's resource identifer between the host component and the path and/or query components, if any

So as far as I understand it, it works correctly.

[pksorensen]

i have a hard time getting my head around that, i dont say it cant be read like you suggest, however no authorizations servers are doing that.

Take microsfot entra ID. thats hots//.well-known - not host/.well-known/tenant id. So we cant use microsoft entra id as a authorization server right now for MCP if this is to be interpreated as that. Not sure if its just me that is seeing it like that

[pksorensen]

from the MCP spec:

step 3 is very clear to me that it should go to /tenant/.well-known

[pksorensen]

so you are also right, but thats step 2 you are refering to. we are missing step 3

[mbroton]

I was referring to you saying that it was not expected. I agree with you that all of this is confusing and I can't even tell if it works as expected or not. I'm struggling since yesterday to make an MCP server work with my custom OAuth server and I was stuck on that step too. In my case, it works like this (Inspector 0.16.2):

Requests a resource server:

• GET /.well-known/oauth-protected-resource/mcp - 404
• GET /.well-known/oauth-protected-resource - 200

Then it goes to auth server (based on metadata from RS):

• GET /.well-known/oauth-authorization-server - 200

And then there's the registration part.

[sebastianguzmanmorla]

There is any way to modify this behavior? I'm using Authentik as a oauth provider and expects the following path: https://xxx.xxxxx.xx/application/o/xxx/.well-known/openid-configuration

[olaservo]

Hi, is this still reproducible with the latest version? We pulled in some changes from the sdk last week which a contributor called out as potentially resolving this issue, but I don't have a quick way to repro at the moment so I could use some help there. Thanks!

[ravij3]

@olaservo - This is still an issue. I see that MCP Inspector still calls the /.well-known/oauth-authorization-server/mcp URL. I tried it on the 0.16.5 release

[mllab-nl]

I have just checked v0.16.5: My use-case is OAuth with Public Client

The inspector allows setting client Id ✅ Using https://github.com/modelcontextprotocol/csharp-sdk/tree/main/samples/ProtectedMcpServer as opensource example: MCP behaves as resource server (http://localhost:7071/.well-known/oauth-protected-resource) pointing to a separate authorization server ("authorization_servers":["https://localhost:7029"])

Initial check - Failed to discover OAuth metadata ❌ A lot of failed cross origin requests in the browser console
Add "Access-Control-Allow-Origin": * to both servers and metadata is resolved ✅ There are some failed requests that contain mcp, but metadata is resolved. ✅

When the authorization server is made to behave as public token is retrieved successfully

Check your browser console for errors and check the CORS headers It is somewhat strange that request are done using the client (browser), I was not expecting this

[cliffhall]

@pksorensen would you mind trying again with 0.16.6? Just want to make sure the latest version of the SDK hasn't provided a fix before investigating further.

[kevklam]

I still see issues with 0.16.7. MCP Inspector seems to ignore the authorization_servers values returned in oauth-protected-resource. The sequence of requests to various oauth-protected-resource and oauth-authorization-server endpoints appears to also vary depending if you click 'connect' and let it attempt to negotiate via the 401 challenge, vs. if you go to the auth settings and manually step through.

In the manual step-through I see the following sequence of requests on the domain of the mcp server: /.well-known/oauth-protected-resource/_api/mcp // results in a 302 to an error page, as this isn't a recognized endpoint /.well-known/oauth-protected-resource // 200 with authorization_servers pointing to a different domain /.well-known/oauth-authorization-server // 404 - request is made to the wrong domain, it ignored authorization_servers /.well-known/openid-configuration // 404 - request is made to the wrong domain it ignored authorization_servers

Aside: Each of the above requests is twinned - not OPTIONS for CORS, presumably because in my test run it already previously passed CORS and that's cached - rather it's making double GETs for every request, once with MCP-Protocol-Version header and once without.

[cliffhall]

I still see issues with 0.16.7. MCP Inspector seems to ignore the authorization_servers values returned in oauth-protected-resource. The sequence of requests to various oauth-protected-resource and oauth-authorization-server endpoints appears to also vary depending if you click 'connect' and let it attempt to negotiate via the 401 challenge, vs. if you go to the auth settings and manually step through.

In the manual step-through I see the following sequence of requests on the domain of the mcp server: /.well-known/oauth-protected-resource/_api/mcp // results in a 302 to an error page, as this isn't a recognized endpoint /.well-known/oauth-protected-resource // 200 with authorization_servers pointing to a different domain /.well-known/oauth-authorization-server // 404 - request is made to the wrong domain, it ignored authorization_servers /.well-known/openid-configuration // 404 - request is made to the wrong domain it ignored authorization_servers

Aside: Each of the above requests is twinned - not OPTIONS for CORS, presumably because in my test run it already previously passed CORS and that's cached - rather it's making double GETs for every request, once with MCP-Protocol-Version header and once without.

We would need to see the requests and their responses and headers to understand why this is happening. Is your server available online or can you provide the repo where the code is?

[halllo]

Seems related to https://github.com/modelcontextprotocol/inspector/issues/576.

Like @ptc-ccrabb mentioned, the RFC9728 is pretty clear that 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.