Repository navigation
Dynamic Client Registration with 3rd party Auth providers (e.g. Okta) #571
Description
Describe the bug
Whenever using the MCP inspector to test an OAuth 2.0 flow, a several issues become evident:
- Dynamic Client registration is enforced in the inspector (can see issue Dynamic client registration should be optional #167 and the PR raised against it already). Private enterprises will not want to expose DCR in all cases, but rather work with clients already registered in another way. (e.g. via API gateways that already handle client registration is one way, and of course it'll vary per organisation)
- Even with Dynamic Client registration, the inspector sending a request to a 3rd party authorization server (example: Okta) on its DCR endpoint (https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/Client/) will lead to a CORS error. However, testing with something like Claude for example - the DCR request is sent successfully with no CORS errors.
To Reproduce
Steps to reproduce the behavior:
- Start the guided OAuth2.0 flow
- Have your .well-known/oauth-authorization-server point to a 3rd party auth server (e.g. Okta/Auth0)
Expected behavior
No CORS error.
Logs
Reacted by Lance Erickson, pokutuna, Marc Nuri, Aaron Zhong, Ryan Kanno, johanhetnplan, kerem and mt-ib
Activity
symdeb commentedon Jul 3, 2025
Perhaps related to the another issue reported that MCP inspector sends an empty body in the client registration request ? it gives the same error with my own Oauth2 authentication server.
dr3s commentedon Jul 25, 2025
I think the issue is that inspector is performing auth as an SPA instead of a backend web api like Claude and others. The latter don't require CORS
olaservo commentedon Oct 13, 2025
There's been a few updates related to the issues mentioned here since it was last opened - @KKonstantinov @cliffhall do you think we can close this now? Thanks!
cliffhall commentedon Oct 18, 2025
You can supply the Client ID and Client Secret in the sidebar.
However, it is a good point that the
/tokenendpoint of the AS may not have CORS open to all origins.We have a another similar complaint which suggests using the proxy for the auth flow. This would require what I believe would be a significant refactor, but it does make sense.
For the ins and outs of what a refactor might require, I suggest we take up the discussion in Discord.
ov-developer commentedon Oct 19, 2025
@cliffhall Maybe adding a
if (connectionType === "proxy") ... else ...inhandleAuthErrorwould already be enough. In case of using the proxy it would call a single oauth endpoint in the proxy, do all the metadata discovery and oauth flow and respond with the access and refresh tokens. For the "OAuth Flow Progress" it is a different story, but it might be enough to just output a warning that no proxy is being used and thus CORS policy applies. Currently it just fails with "Failed to discover OAuth metadata".cliffhall commentedon Aug 1, 2026
Triage: Priority = High
Scored 9/16 with the priority rubric added to
AGENTS.mdin #1891, as part of the backlog triage in #1872. Added to project board #28 with Status Incoming — meaning filed and scored but not yet approved for work. A maintainer decides whether it moves to Todo.buglabel (+1), high engagement (5 comments, 8 reactions) (+1)Related issues. These look connected and may be worth reading together:
Scores are a starting point, not a verdict — the rubric is meant to be overruled when it's plainly wrong, provided the reason is written down.
symdeb commentedon Aug 3, 2026
My particular issue with CORS were resolved updating to a new version of PHP (From 7 to 8 I believe) and make the related changes for header in php code for the response itself. The OAUTH2 server with DCR and the well-known endpoints now work fine (on a localhost). With PHP 7 even adding the related headers sin .htaccess could not fix the issue.