modelcontextprotocol
OAuth Config (Optional) for Remotes
An optional, OAuth server configuration could help here as well specifically for those MCP authorizations servers that do not support Dynamic Client Registration.
Described in the spec, Clients could hardcode the ClientId for the authorization server.
The metadata in the registry can help guide consumers a ClientId is expected for the specific MCP server as well as where to acquire it, usually link to service provider developer portals.
For reference see issue - https://github.com/microsoft/vscode/issues/247759 and also briefly touched on DCR topic and clientId acquisition in the blog
The shape of this could be inspired from OAS and/or PRM
Created for tracking from PR comment - https://github.com/modelcontextprotocol/registry/pull/3/files/e9ad7352dd35f905e6216b94cf760d6bd124d8a0#r2077901936
One thing not immediately obvious to me from reading this description: would this piece of work result in a reliable way to determine the answer to, "what account on what service do I need to have to be able to use this MCP server?"
For example, I'm wondering if this metadata will be enough to know that "I need an account on anthropic.com to log in to this MCP server," or if this level of metadata might do something more obscure like surface an "auth0.com" URL (assuming Anthropic delegates auth concerns to auth0) without indication that the user-facing requirement is an account on anthropic.com (and not an account on auth0.com).
I think that is a helpful piece of metadata to somehow allow incorporating for every remote server (if there is an OAuth gate present), so if not as part of this Issue, we should consider working it in elsewhere.
With the recent changes in the auth spec, most of this metadata is returned during the initial auth handshake as PRM. Probably the only metadata that is currently required that the registries can supply is the static client Id to skip the DCR; This is particulary helpful dealing with AS that don't support them yet or always want their users to acquire it beforehand. I now see claud.ai integrations provides such a capability to feed in "clientId".
This could be for now solved with extensions proposal https://github.com/modelcontextprotocol/registry/issues/81 but would be good to add to the registry spec for predictability for consumers. default - DCR; clientId provided use this together with PRM returned. Also can provide metadata on the developer portal to navigate to, to acquire this clientId. Most systems I assume will be in the later boat in foreseeable future.
@annaji-msft are you able to write up a spec for exactly what metadata is needed here, ideally in the next few days? (or find someone who can). I think that would make this ask a lot clearer to me at least (as someone who hasn't built a client that has to handle oauth servers I'm worried I might miss some info that is important etc.).
It might also be useful to include notes on whether this is a go-live blocker. I'd lean towards it being a blocker if it's needed for clients to reliably connect to servers AND it's hard to backfill in later through inspecting servers etc. My guess is the two are probably correlated though.
@domdomegg - Hey, this is what we have on our side to support remote OAuth/OIDC configurations - https://github.com/stacklok/toolhive/blob/main/pkg/registry/types.go#L132-L150
We can use it as a starting point/reference if helpful 👍
cc: tagging @JAORMX and @amirejaz who worked on it
The metadata in the registry can help guide consumers a ClientId is expected for the specific MCP server as well as where to acquire it, usually link to service provider developer portals.
I've been thinking about this a bit more, and wouldn't servers that require a client id need to already declare it as something like an environment variable / runtime argument already? So it should already be obvious from the server.json whether this will need extra configuration in that way (and these can have a description which describes how to go and get the client id etc.).
On a meta level, I might propose we downgrade this from 'go-live blocker' - it seems like adding this metadata would be a non-breaking change to server.json (as it would just be adding optional properties), and it seems like the use case is more on the 'nice to have' side rather than 'crucial' for registry to add value/not get stuck in an irreversibly bad situation.
Hey team, what’s the status with this? Appreciate the discussion to fully describe each server’s auth requires more work - but is there room to record at least if it’s oauth/open/api-key before that?
@jaw9c I agree that it would be helpful to include some sort of high level auth_mechanism field on the Remote shape, very open to proposals for adding that to server.json