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