Dynamic Client Registration with 3rd party Auth providers (e.g. Okta)

[KKonstantinov]

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 #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:

1. Start the guided OAuth2.0 flow
2. Have your .well-known/oauth-authorization-server point to a 3rd party auth server (e.g. Okta/Auth0)

Expected behavior No CORS error.

Logs

[symdeb]

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]

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]

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]

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!

You can supply the Client ID and Client Secret in the sidebar.

However, it is a good point that the /token endpoint 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]

@cliffhall Maybe adding a if (connectionType === "proxy") ... else ... in handleAuthError would 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".