Dynamic Client Registration (DCR)
When to Use This Skill
- Setting up Dynamic Client Registration (DCR) at
/connect/dcr - Securing the DCR endpoint with authorization policies
- Customizing DCR validation with
DynamicClientRegistrationValidator - Implementing software statement validation
- Persisting dynamically registered clients with
IClientConfigurationStore - Hosting DCR in a separate application from IdentityServer
Core Principles
- DCR requires the
Duende.IdentityServer.ConfigurationNuGet package - Requires Business Edition or higher license
- Always secure the
/connect/dcrendpoint with an authorization policy — never expose it unauthenticated - Enforce PKCE and restrict allowed grant types in the DCR validator
- Use persistent stores (database) for dynamically registered clients in production
Docs: https://docs.duendesoftware.com/identityserver/configuration/dcr
Overview
Dynamic Client Registration allows clients to register themselves at the /connect/dcr endpoint per RFC 7591. This feature requires the Business Edition or higher and has been available since version 6.3.
DCR uses a separate NuGet package and can be hosted in the same application as IdentityServer or in a separate host.
Setup
MapDynamicClientRegistration() is an endpoint-routing extension from the Duende.IdentityServer.Configuration package (separate from Duende.IdentityServer). Call it where you configure the pipeline/endpoint routing — in the quickstart/template hosts this is the ConfigurePipeline() method (HostingExtensions.cs), alongside UseIdentityServer(). AddIdentityServerConfiguration() registers the DCR services; MapDynamicClientRegistration() maps the /connect/dcr endpoint. Both are required.
Securing the DCR Endpoint
Apply standard ASP.NET Core authorization policies to the DCR endpoint:
DCR Request and Response
Registration request:
Registration response:
Customizing DCR Validation
Extend DynamicClientRegistrationValidator to add custom validation logic:
Register:
DynamicClientRegistrationContext
The context object passed to validation methods contains:
Software Statements
Software statements are signed JWTs that contain pre-approved client metadata. Validate them by overriding ValidateSoftwareStatementAsync:
Other DCR Extensibility Points
Client Configuration Store
DCR needs a persistent store for dynamically registered clients. Use the Entity Framework implementation:
Or implement IClientConfigurationStore for a custom backing store:
Separate DCR Host
DCR can be hosted in a separate application from IdentityServer:
Common Anti-Patterns
-
Exposing the DCR endpoint without authentication — Always secure
/connect/dcrwith an authorization policy. -
Allowing dynamically registered clients to use any grant type — Restrict allowed grant types and enforce PKCE in the DCR validator.
-
Using in-memory stores for DCR clients in production — Use persistent stores (database) for production deployments.
Common Pitfalls
-
Business Edition requirement:
AddIdentityServerConfiguration()requires a Business Edition or higher license. Community Edition does not support DCR. -
Client secrets: Dynamically registered clients receive generated secrets. Ensure your
IClientConfigurationStorestores these securely (hashed, not plaintext). -
Software statement trust: Software statements must be validated against a trusted signing key. Do not accept software statements signed by unknown issuers.
-
Separate host connectivity: When hosting DCR separately, it must be able to communicate with IdentityServer's data stores. Ensure the
IClientConfigurationStoreis backed by the same database that IdentityServer reads from (or uses a shared data layer).
Related Skills
identityserver-configuration— IdentityServer host configuration, client types, grant types, secret management, and resource configurationidentityserver-saml— SAML 2.0 Identity Provider (the other advanced IdentityServer feature)identityserver-stores— Persistent store patterns (useful for customIClientConfigurationStore)aspnetcore-authorization— Authorization policies for securing the DCR endpointidentity-security-hardening— Security hardening including HTTPS enforcement



