The inspector does not follow the spec according to authorization senarios

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

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.

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

from the MCP spec:

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

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

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.

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

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!

@olaservo

@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

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

@pksorensen

@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.

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.

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?

@ptc-ccrabb

Seems related to #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.

This should be fixed by PR #702. Closing - please reopen if you're still experiencing this issue.

This comment was posted by Claude during issue triage.

I’m not sure if this is the proper place to comment, but I’m seeing a similar issue with MCP Inspector, while other AI assistants such as Claude, Copilot, etc., work fine.

Case:

MCP Server : https://a-domain/mcp
Authorization Server (AS): https://b-domain

When my MCP server receives a POST https://a-domain/mcp request from MCP Inspector without a bearer token, it returns a 401 response with resource_metadata, for example:

Bearer realm="mcp", resource_metadata="https://a-domain/.well-known/oauth-protected-resource"

MCP Inspector then performs a GET https://a-domain/.well-known/oauth-protected-resource, which returns the authorization_servers metadata from b-domain:

{
  "resource": "https://A/mcp",
  "authorization_servers": ["https://b-domain/"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["profile"]
}

However, MCP Inspector attempts to retrieve OIDC or Authorization Server discovery metadata from a-domain instead of b-domain, which is specified in the authorization_servers parameter.

If I try the same flow with other AI assistants, it works correctly.

Any help would be appreciated.

In my case, I have a predefined client ID and secret configure in OAuth 2.0 Flow setting, because I do not want to use DCR. However, I believe this should not affect the behavior.

This indeed seems to be a bug.

It seems like inspector is not respecting Section 4.3 of the spec. The spec indicates that the metadata endpoints to be tested are relative to the issuer and not the resource.

issuer - The issuer is the .authorization_servers[0] value from the protected resource metadata document.
resource - The resource is the .resource value from the protected resource metadata document and will often be the same as the MCP server itself (but is not required to be).

Crucially, the resource doesn't even need to be a url. It could be any opaque value. The contract is that the MCP Client constructs an authorization endpoint url like /authorize?resource. The MCP Server will expect tokens issued from that flow to have the aud claim that matches their configured resource value (which will often, but not always be the MCP Server URL itself).

Fix OAuth: use authorization_servers URL from resource metadata for a…

Fix incoming for this: #1133

Closing: v1 is deprecated.

Thank you for reporting this, and apologies for the long wait for a response.

v1 will receive security fixes only — this issue describes a functionality, compatibility, or usability problem rather than a vulnerability, so it is being closed against v1. This is not a judgment on whether the problem is real — it's a consequence of the v1 line being frozen. This is happening as part of #1872.

If this still happens in v2, we'd genuinely like to know. v2 is a complete rewrite — three clients over a shared core — so many v1 behaviours no longer exist in the same form. Please open a fresh issue against v2 with steps to reproduce, and we'll look at it. Note that we accept external contributions as issues rather than pull requests; maintainers handle design and implementation through a prompt-driven workflow. See CONTRIBUTING.md.

Thanks for taking the time to report it.

Navigation Menu

Repository navigation

The inspector does not follow the spec according to authorization senarios #675

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The inspector does not follow the spec according to authorization senarios #675

Description

Activity

mbroton commented on Aug 6, 2025

pksorensen commented on Aug 6, 2025

pksorensen commented on Aug 6, 2025

pksorensen commented on Aug 6, 2025

mbroton commented on Aug 6, 2025

sebastianguzmanmorla commented on Aug 8, 2025

olaservo commented on Aug 20, 2025

ravij3 commented on Aug 21, 2025

mllab-nl commented on Aug 25, 2025

cliffhall commented on Sep 5, 2025

kevklam commented on Sep 16, 2025

cliffhall commented on Sep 17, 2025

halllo commented on Sep 18, 2025

olaservo commented on Jan 18, 2026

embesozzi commented on Feb 25, 2026

ggoodman commented on Mar 6, 2026

cliffhall commented on Mar 8, 2026

segevfiner commented on Mar 16, 2026

cliffhall commented on Aug 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions