Incompatible DCR Flow When `registration_endpoint` Requires Credentials (e.g., with Okta)

[asparsh29kumar]

Describe the bug
When following the Model Context Protocol (MCP) flow with support for [RFC 9728 - OAuth 2.0 Protected Resource Metadata], it appears that the use of dynamic client registration (DCR) is not compatible with authorization servers like Okta that require a pre-provisioned API key to access the registration_endpoint. As a result, even though the client correctly discovers the registration_endpoint via protected resource metadata and authorization server metadata, it cannot actually register dynamically — defeating the purpose of DCR in this context.

To Reproduce
Steps to reproduce the behavior:

1. Set up a protected resource (e.g., API) that advertises authorization_server metadata at /.well-known/oauth-protected-resource.
2. Ensure the authorization server is Okta.
3. Discover the registration_endpoint via Okta’s /.well-known/oauth-authorization-server.
4. Attempt to register dynamically as a client without an API key.
5. Observe that the request fails due to the lack of authorization (API key requirement).

Expected behavior
The client, after discovering the registration_endpoint through the standard metadata flows, should be able to perform dynamic registration without requiring out-of-band administrator credentials like an API key. The assumption behind DCR is that it allows dynamic, client-initiated onboarding — not manual administrative provisioning.

Additional context
This limitation seems to undermine the goal of using OAuth protected resource metadata to dynamically discover and register clients. If the authorization server’s DCR endpoint requires prior admin-level authorization (e.g., an API key), the dynamic nature is effectively broken.
Dynamic client registration in Okta according to Okta developer documentation:

curl -i -X GET \
  https://subdomain.okta.com/oauth2/v1/clients \
  -H 'Authorization: YOUR_API_KEY_HERE'

[pcarleton]

Hi @asparsh29kumar,

The MCP Protocol follows RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol which allows for registration endpoints to require a token.

The client registration endpoint MAY be an OAuth 2.0 [RFC6749]
protected resource and it MAY accept an initial access token in the
form of an OAuth 2.0 access token to limit registration to only
previously authorized parties. The method by which the initial
access token is obtained by the client or developer is generally out
of band and is out of scope for this specification. The method by
which the initial access token is verified and validated by the
client registration endpoint is out of scope for this specification.

To support open registration and facilitate wider interoperability,
the client registration endpoint SHOULD allow registration requests
with no authorization (which is to say, with no initial access token
in the request). These requests MAY be rate-limited or otherwise
limited to prevent a denial-of-service attack on the client
registration endpoint.

In the case of MCP and DCR, the language is also a SHOULD, not a MUST:

MCP authorization servers and MCP clients SHOULD support the OAuth 2.0 Dynamic Client Registration Protocol (RFC7591).

So Okta in this case is choosing to require an authorization token, which is still compliant with the spec (SHOULD vs. MUST). It may reduce interoperability, but ultimately that is up to the server implementor.

[asparsh29kumar]

Hey @pcarleton! Thank you for the response.

Just to confirm — since DCR support in MCP is a SHOULD and not a MUST, does that mean it's effectively just a recommendation and not required for MCP compliance?

Also, if DCR is optional, what alternative approaches are commonly used or considered acceptable for client registration in this context?

Lastly, what's generally considered the best path forward for an auth server like Okta in an MCP ecosystem? Is the MCP server expected to adapt to whatever the client's chosen auth server supports, or is there a more standardized expectation around how this should be handled?