Alternative For DCR (Dynamic Client Registration)

[philip-ulrich]

I'm not sure how much of this comes down to this implementation vs how the standard for MCP servers are defined - but I'd like to remove some of the risk of DCR. A lot of enterprise environments don't even have it enabled and really it only needs to exist at the MCP Server level. Then you have have registered MCP servers and don't risk having malicious ones that auto log someone in and scrap their token.

Would it be within scope to implement DCR within the lib? Or at the very least add some sort of way to add headers to pass a token on to the OAuth servers to protect registration (and realistically, all the calls). IMO, the former would be the most ideal.

[xiaoyijun]

Hi @philip-ulrich , thanks for bringing this up — it’s a really good point and worth discussing in more detail.

From my perspective, implementing DCR directly inside the lib may not be the best approach, since the actual registration request is ultimately initiated by the MCP Client, not the lib itself. So even if we were to handle the registration inside the lib, the risk of abuse still exists — the only difference would be whether the MCP Client registers directly with the IdP or indirectly through the MCP Server via the lib.

That’s why we’ve leaned toward supporting pre-registered clients instead — and why the MCP Client is designed to accept a pre-provisioned Client ID. This ensures better control and avoids the security risk of dynamic registrations entirely.

Did I understand your concerns correctly? I’d really like to make sure we’re on the same page and continue the conversation to find the right balance here.

[philip-ulrich]

Thanks for the reply. I don’t think that would cover the particular threat vector we are concerned about - since the client is ultimately still the application.

Presently we aren’t super concerned about the application connecting (this will probably change to be honest), but we are concerned about having rouge mcp servers acting as a middle man and intercepting credentials. Since the MCP Server does no verification, but has full access to the federated credentials that’s a problem. An amplified problem in my case for reasons I can’t go into.

Even if we moved to pre-registered clients, I still don’t think the MCP server would be doing any verification before getting user tokens aside from just the user logging in and potentially clicking a button that says “sure, I trust this app”. Which in it’s current form is a background process with how we have it setup.

I guess the issue is less around DCR and more about the current auth proxy situation at the MCP server level. It just presented itself as a problem I could “solve” or make less problematic by either of the above options.

Side tangent: Even if we moved to pre-registered clients, I don’t really think that secures the DCR part since we likely still won’t have a secret at the client level. Or the secret won’t really be secret - so something could pretend to be a Claude desktop app, but not really be. I’m really more on the lax side typically when it comes to this stuff, but I’m going to be fighting with people that are very strict so I’m having to go down a bunch of strange rabbit holes. 😆

[philip-ulrich]

The more I consider what we need to do in the current form, the more it looks like we're just going to have to maintain our own custom library. I don't think we're the only ones going to be in this situation, but I also don't know if this library should be the thing that solves it.

[xiaoyijun]

Thanks for the detailed thoughts! Just to follow up: with pre-registered clients, each client would provide its own redirect URI, and the auth service will strictly validate this redirect URI. Combined with PKCE, even for public clients, the threat you mentioned could be greatly mitigated.

As for support for dynamic clients, based on the current protocol—especially since the MCP server acts as a resource server—it seems like there isn’t much that libraries like this can really do.

Maybe using the Backends for Frontends (BFF) pattern could be a good approach, but from what I can see, the MCP Auth protocol doesn’t mention any guidance or implementation for this.

We’ll try to propose this to MCP, but for now we’ll just have to follow the current MCP spec (i.e., DCR support depends on how the Auth Server is implemented).