Implement Dynamic Client Registration (RFC 7591/7592) support

[maliming]

Confirm you've already contributed to this project or that you sponsor it

• I confirm I'm a sponsor or a contributor

Version

7.2.0

Question

I want to ask if there are any plans.

Thanks.

[kevinchalet]

Hey @maliming,

Backported from OIDC, "dynreg" isn't really a recent thing but in practice, very few services offer it due to the fact it's generally regarded as a massive security risk (specially if the registration step doesn't require an initial access token). As such, the demand for dynamic client registration and dynamic client registration management support in OpenIddict has been - so far - pretty much non-existent 😄

In abpframework/abp#24193, @itw-DheerG said he was interested in seeing this feature supported to be used with MCP but it's worth noting that dynreg is NOT the recommended approach to "register" a new client application:

For MCP, OAuth Client ID Metadata Document is the recommended approach, but it's still a WIP (the first draft shipped in October: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00).

If dynreg is important to have in ABP, I'm happy to add it, but we need to make sure there's a real use case for that before implementing such a niche feature 😃

More info here: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization

[thoraj]

Will you consider making the changes to support CIMD?

We are currently using Duende IdentityServer, community edition, and must soon upgrade to a paid tier. Depending on what kind of support and licensing they will offer for CIMD (and MCP supporting scenarios), we will also consider contributing and/or sponsoring OpenIdDict as an alternative.

[hikalkan]

Thanks @kevinchalet for your answer. I closed the related ABP issue: abpframework/abp#24193 (comment)

[kevinchalet]

Will you consider making the changes to support CIMD?

As I mentioned in the PR you submitted (thanks again for that), it's too early for that. There's no doubt there will be significant changes to the specifications and I don't want to rush such a risky/dangerous feature.

That said, I'm considering adding DynReg/DynReg management support (likely as part of a major version as I'm sure we'll need to introduce new first-class properties in the EF/MongoDB entities).

[fluto7]

@kevinchalet
I would like to add our use case to strongly support the implementation of OAuth 2.0 Dynamic Client Registration (DCR).
We are currently operating a platform that complies with the 1EdTech Open Badges 3.0 standard. In this educational credential ecosystem, DCR is a fundamental requirement.
Specifically, DCR is essential for the following scenarios:
• When a user's wallet receives credentials from various external institutions.
• When querying a user's credentials hosted on different external platforms.
Because this standard relies heavily on dynamic federation and trust between diverse issuers and wallets, having a robust, pre-implemented DCR feature in OpenIddict would drastically reduce the implementation burden for developers in this sector.
If OpenIddict supports DCR natively, it will not only resolve our immediate technical hurdles but also significantly activate the broader ecosystem surrounding verifiable credentials and Open Badges.
Thank you for your great work and for considering this feature request.