MCP Inspector OAuth: CORS error on dynamic client registration with Okta/third-party AS?
When using MCP Inspector's guided OAuth 2.0 flow with a third-party authorization server such as Okta or Auth0, the dynamic client registration request fails with a CORS error. Is there a supported way to use a pre-registered client or otherwise get past this error?
Originally asked on GitHub: https://github.com/modelcontextprotocol/inspector/issues/571
6 answers
The issue is closed as completed, but the thread does not claim a fix that removes CORS requirements from third-party authorization servers. The maintainer-supported workaround is to supply an already-registered Client ID and Client Secret in the Inspector's OAuth sidebar so the flow skips dynamic client registration (DCR); this was noted as available, although no commenter reported an end-to-end test of it. For the remaining CORS problem, a maintainer noted that the authorization server's /token endpoint may not have CORS open to all origins. A proxy-based auth flow was proposed in a comment, but maintainers said that would require a significant refactor and moved the detailed discussion to Discord. One contributor believed the root cause is that Inspector performs auth as an SPA, while Claude and other clients act like backend web APIs and do not hit CORS; that explanation was presented as a hypothesis, not confirmed in the thread. Separately, one commenter with a self-hosted OAuth2 server fixed the same CORS errors on localhost by upgrading from PHP 7 to PHP 8 and setting CORS headers in PHP response code, where .htaccess alone had not worked. For organizations that do not want to expose DCR, maintainers also linked issue #1150 about Client ID Metadata Documents as the spec-sanctioned alternative.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Started the guided OAuth 2.0 flow with .well-known/oauth-authorization-server pointing to a third-party authorization server such as Okta or Auth0. The Inspector's dynamic client registration request to that server produced a CORS error.
Source: https://github.com/modelcontextprotocol/inspector/issues/571 (opens external site)
Did this work for you?What @symdeb tried on GitHub (Didn't work)
Reproduced the same error against their own OAuth2 server and suspected Inspector sends an empty body in the client registration request. No fix came from this observation.
Did this work for you?What @cliffhall tried on GitHub (Outcome unclear)
A maintainer said the OAuth sidebar accepts an existing Client ID and Client Secret, letting the flow bypass dynamic client registration. The thread does not include a user report confirming this end-to-end.
Did this work for you?What @ov-developer tried on GitHub (Outcome unclear)
Suggested handling a proxy connection type in handleAuthError so the flow would go through a single proxy OAuth endpoint and avoid CORS. Maintainers said a proxy refactor would be significant and moved discussion to Discord.
Did this work for you?What @symdeb tried on GitHub (Worked)
On a self-hosted OAuth2 server, upgraded from PHP 7 to PHP 8 and set CORS response headers in PHP code. Dynamic client registration and well-known endpoints then worked on localhost.
Did this work for you?
Related questions
- MCP Inspector 0.10.2 sends null for unset optional params (error -32602)?
- Why does npx @modelcontextprotocol/inspector fail with 'mcp-inspector: command not found' after 0.10.0?
- How do I increase MCP Inspector's 10-second request timeout?
- MCP Inspector crashes with 'Controller is already closed' on fastmcp Streamable HTTP
- Why does the MCP Inspector Docker container refuse connections on localhost:6274, and how do I fix it?