Skip to content

feat: allow OIDC configuration for OAuth server #585

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

feat: allow OIDC configuration for OAuth server #585

wants to merge 2 commits into from

Conversation

joshcanhelp
Copy link

@joshcanhelp joshcanhelp commented Jun 3, 2025 •
edited
Loading

The MCP authorization spec relies on a specific metadata URL to be published by the authorization server, as described in RFC 8414. There is also a metadata endpoint that's used for OIDC discovery that has very similar information:

https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig

It seems like either could be used for AS metadata, especially since the client could be trying to obtain an identity. I don't want to run afoul of the MCP spec but this seems like it serves the same purpose and would be a good stop-gap in case an identity provider does not publish the OAuth-specific endpoint.

Motivation and Context

I am using Auth0 as an identity provider and they publish the OIDC endpoint:

http://auth0.auth0.com/.well-known/openid-configuration

... but not the OAuth one:

https://auth0.auth0.com/.well-known/oauth-authorization-server

How Has This Been Tested?

npm test and I ran it locally using this:

geelen/mcp-remote#102

Breaking Changes

The OAuthClientProvider.useOidcProviderConfiguration() method should probably be a getter but that would make this breaking since you can't have an optional getter in TS. So, no, no breaking changes.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed - Happy to add this if this PR is accepted

Additional context

The differences between the OpenID and OAuth metadata are minimal and are mainly things that the OpenID config has that the OAuth one doesn't (for Okta it's the id_token_signing_alg_values_supported, jwks_uri, and userinfo_endpoint properties). In other words, the OpenID one can be used as-is. Everything that is required for the OAuth metadata is also required for the OpenID one:

  • issuer
  • authorization_endpoint
  • token_endpoint
  • response_types_supported

@joshcanhelp joshcanhelp mentioned this pull request Jun 3, 2025
Draft
@joshcanhelp joshcanhelp marked this pull request as ready for review June 3, 2025 17:09
@shays10
Copy link

shays10 commented Jun 4, 2025

@joshcanhelp I've encountered this issue myself while integrating with my Authorization Server, so I appreciate the work on this - thanks!

I have a quick question:

As an MCP server developer (who doesn't control the MCP client and isn't using mcp-remote), is there a way to signal to the MCP client that it should use /.well-known/openid-configuration instead of /.well-known/oauth-authorization-server?

For me currently, the MCP client fails with a 404, and after this PR is merged, it seems like MCP server developer will need a way to instruct the MCP client to set useOidcConfig to true.
Is there a recommended approach for this scenario?

Hope that makes sense.

@joshcanhelp
Copy link
Author

@shays10 - Happy to help!

You can see what I'm doing in the mcp-remote PR even if you're not using it directly. TL; DR: the OAuthClientProvider now has a method you can define in your auth provider that will trigger that new path.

Your reply says you don't control the client so that's going to make this challenging. What client are you using? Does it use this SDK?

@shays10
Copy link

shays10 commented Jun 4, 2025

Your reply says you don't control the client so that's going to make this challenging. What client are you using? Does it use this SDK?

@joshcanhelp Ideally, and please correct me if I’m overlooking something, this should be client-agnostic.

As a MCP server developer exposing the /.well-known/oauth-protected-resource endpoint, I already know which AS the MCP client is expected to use for the OAuth flow. And since my AS only exposes /.well-known/openid-configuration, I would like the OAuth flow to work with any client adhering to the specification.

I can think of a couple of potential approaches, though I’m unsure of their validity:

  1. The server could indicate to the client that it should call /.well-known/openid-configuration, perhaps by including that information in the /.well-known/oauth-protected-resource response.

  2. The client could first attempt to fetch /.well-known/oauth-authorization-server, and fall back to /.well-known/openid-configuration if necessary.

I’m still wrapping my head around this, curious if this direction makes any sense.

@joshcanhelp joshcanhelp force-pushed the feat/add-oidc-config branch from 62f110d to 10959c2 Compare June 5, 2025 22:23
@joshcanhelp
Copy link
Author

@shays10 - We're kind of running into the problem with this not being spelled out in the spec. IMHO, both should be supported since they share the properties that make this work and they are there to direct clients on what to do. Best path forward here is to spell it out in the spec:

  1. Look for .well-known/oauth-authorization-server
  2. Fall back to .well-known/openid-configuration
  3. Fall back to defaults

In the end, neither the MCP Client (Client going forward) nor the MCP Server (Server going forward) should care at all where the metadata is located. The Client checks the Server metadata, Server points to the Auth server, Client knows where to get metadata because of the spec, everything works.

In short, I think your option 2 makes the most sense overall. I'm hoping this SDK can be updated for that to unblock those of us that need it, then it can make it in the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@joshcanhelp @shays10