feat: validate dynamic client registration #96
Conversation
🦋 Changeset detectedLatest commit: 34f421e The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
There was a problem hiding this comment.
The whole point of DCR is to let arbitrary clients register with the service. An MCP server, for example, wants to allow any agent to use it, including agents the service owner hasn't heard of.
So what validation can they possibly do?
If you have a server that doesn't want to allow everyone to register, then you should turn of DCR, and instead issue client credentials to the specific clients that you want to allow, or implement an alternative registration mechanism that matches your business needs.
I see your point - I was under the assumption that DCR could still be useful for organizations that want to enable dynamic registration for clients within their own domain. For example, an internal MCP server might allow DCR for all clients hosted on the same domain, or maybe just for trusted internal tools and editors. In that kind of controlled environment, DCR could still make sense without opening it up to arbitrary external clients. |
|
I could be convinced that "DCR with restrictions" makes sense for certain use cases, but I think we need to enumerate real-world use cases before we design a solution. Meanwhile I've heard MCP is moving away from DCR so maybe this problem will go away soon anyawy. |
This change introduces a new
validateClientRegistrationcallback to theOAuthProvideroptions, enhancing the security of the dynamic client registration feature.The Problem
Previously, when the
clientRegistrationEndpointwas enabled, the library allowed any client to register without restriction. This posed a security risk, as it could allow malicious or unauthorized clients to be registered with the OAuth provider.The Solution
To address this, I have added a new optional callback function,
validateClientRegistration, to theOAuthProviderOptions. This function is executed before a new client is registered and allows developers to implement custom validation logic.The callback receives the
clientMetadataand the original request as arguments and should return abooleanvalue indicating whether the registration is allowed. If the function returnsfalse, the registration is denied with a 403 Forbidden error.I have also updated the
README.mdto:validateClientRegistrationcallback to secure the dynamic client registration endpoint.This change empowers developers to enforce their own policies on client registration, such as allowlisting specific domains for redirect URIs or requiring an authentication token for the registration request.