Regression in OAuth 2.0 Flow with Client ID in 0.16.8

[sberyozkin]

Inspector Version

• 0.16.8

Describe the bug

MCP Inspector fails to complete the authorization code flow, it starts spinning after a user logs-in to the OAuth2 provider (Keycloak) and is redirected back to MCP Inspector

To Reproduce
Steps to reproduce the behavior:

1. Check out https://github.com/quarkiverse/quarkus-mcp-server
2. No need to build anything, just go to https://github.com/quarkiverse/quarkus-mcp-server/tree/main/samples/multiple-secure-mcp-http-servers
3. Do mvn quarkus:dev - it starts the MCP server, and launches a Keycloak container
4. In MCP Inspector: set address to http://localhost:8080/mcp, Transport Type: Streamable HTTP, OAuth2 Client id - alpha-client, scope: openid quarkus-mcp-alpha
5. Press Connect - you are redirected to Keycloak, login as user alice, password alice, you are redirected back to MCP Inspector, no option to select tools is offered, MCP Inspector is in the loop in the console and Web Developer Tools/Network

Expected behavior
It should work exactly as it works with 0.16.7 - after the login, MCP Inspector does not spin, a user is offered an option to select tools. See this description.

Screenshots
it is hard to capture anything specific - 401 errors are reported in the console, Web Developer Tools/Network shows MCP Inspector is looping

Environment (please complete the following information):

• OS: Fedora 42
• Firefox

Additional context

Let me know if I can help with some extra info.
The Quarkus blog post is due to go today and I had to update the text to recommend users to hold on to the 0.16.7.

[sivankri]

Hi Team, i am facing same issue. Is there any workaround currently?

[olaservo]

I have not personally reproduced this yet, but setting to P1 since it appears to be a blocking issue with multiple reports and upvotes.

[max-stytch]

I was able to repro! Some debugging notes:

It does look like the OAuth request succeeds, and a token is issued.

Something fails within the MCP connection itself (I'm not sure what, yet) and then the MCP client issues a refresh token request, which succeeds.

The client tries again with the new token, which fails again, which triggers a new refresh token request, which succeeds, so the client tries again with the new token, entering into an infinite loop.

So something is definitely up, but I don't think it is related to the OAuth redirect URL PR since a token is definitely being returned.

[max-stytch]

Found it! Although an access token was returned, the bearer header isn't being sent

This looks like it is triggered by the custom header placeholder that is added automatically when the Authentication toggle is opened.

Deleting the custom header restores the correct access token, and everything works again.

That means this issue is a duplicate of #829 and should be addressed by https://github.com/modelcontextprotocol/inspector/830 - cc @olaservo @cliffhall if we want to get this out faster since it fixes the p1.

There's an immediate workaround available of deleting the custom header but it is quite annoying to put on the user every time.

[rgwood-dd]

FYI, we're still seeing auth issues with v0.17.0 (which looks like it includes #830 ). When attempting to connect to our streamable HTTP server, it fails and prints these errors over and over in the console:

Error from MCP server: Error: Error POSTing to endpoint (HTTP 401): {"errors":["Unauthorized"]}
    at StreamableHTTPClientTransport.send (file:///Users/reilly.wood/.npm/_npx/5a9d879542beca3a/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:284:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
New StreamableHttp connection request
Query parameters: {"url":"https://mcp.datadoghq.com/api/unstable/mcp-server/mcp","transportType":"streamable-http"}
Created StreamableHttp client transport
Client <-> Proxy  sessionId: 39255045-36f7-4b2a-8b6e-a605c30f2e69
Error from MCP server: Error: Error POSTing to endpoint (HTTP 401): {"errors":["Unauthorized"]}
    at StreamableHTTPClientTransport.send (file:///Users/reilly.wood/.npm/_npx/5a9d879542beca3a/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:284:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
New StreamableHttp connection request
Query parameters: {"url":"https://mcp.datadoghq.com/api/unstable/mcp-server/mcp","transportType":"streamable-http"}
Created StreamableHttp client transport
Client <-> Proxy  sessionId: efbe8892-4baa-4494-9801-8b5c28b41777

In the UI we see an "Invalid Authorization Header" error:

Workaround

Downgrade to v16.7 with npx @modelcontextprotocol/inspector@0.16.7

[cliffhall]

@rgwood-dd Did you try disabling the header? This header should be off by default, unless in a previous version you had sent it and it is in your local storage. Try clearing your local storage if disabling it doesn't work.

[rgwood-dd]

I did not try that, I should have read the error message more closely 🤦

Disabling that solves the issue, and it works by default after clearing my local storage. Thank you!

[sberyozkin]

Good job