Dynamic Client Registration Overview
On this page
What is Dynamic Client Registration?
Dynamic Client Registration (DCR) is an important feature of the OpenID Connect and OAuth 2.0 frameworks. It allows OAuth client applications to register with an authorization server at runtime instead of requiring manual configuration. It is standardized by both the OpenID Foundation in the OpenID Connect Dynamic Client Registration and by the IETF as RFC 7591. These specifications define how a client may submit a request to register itself and the response that the authorization server should provide. Dynamic client registration is particularly useful in scenarios involving multi-tenant architectures, federated identity, and large-scale applications where pre-registering every client is impractical.
This article explains the basics of dynamic client registration, when it is useful and what it entails.
The Basics of Dynamic Client Registration
With dynamic client registration the client submits a registration request with its desired client metadata to the client registration endpoint at the authorization server. The authorization server processes the request and responds with the client details that it registered including a client ID and, in some cases, a client secret.
- The client sends a POST request to the authorization server's client registration endpoint with an optional initial access token and the metadata that it wants the server to register.
- The authorization server processes the request, registers a new client, and responds with the client details that it recorded.
The response may also include a registration access token, which enables self-service management for the client, like updates and deletions of the registered metadata using OAuth 2.0 Dynamic Client Registration Management Protocol.
Use Cases for Dynamic Client Registration
There are three primary use cases for dynamic client registration:
- Mobile application instances register to get an installation-specific credential.
- Administrators use a developer portal or API management system to register clients with the authorization server.
- Applications are part of an open ecosystem and should be able to register at will.
Mobile Application Instances
This use case covers mobile applications on users' devices like iOS, Android, or other platform-specific applications that need to obtain an access token to securely communicate with APIs. Compiling and distributing a client credential with an application is not secure because reverse engineers can extract it from the application with relative ease. Consequently, such a credential is not truly secret, and an application with such a credential is basically a public client.
Public clients imply additional security risks. In particular they cannot protect a refresh token with a client credential. Therefore, authorization servers may not issue refresh tokens to public clients. Without refresh tokens, an application needs to trigger a new user-facing flow with potential re-authentication every time its access token expires, which results in a very poor user experience (UX). Because of this implication, in many setups, the authorization server returns refresh tokens to non-confidential mobile clients despite the security risks.
Dynamic client registration enables installation-specific client ID and secret, which reduces the security risks of mobile applications. It implies that the application can register itself at the authorization server as part of its installation procedure and receive a client ID and secret that is unique to that installation -- the instance of the application. This credential is created at runtime, and reverse engineers cannot retrieve it by analyzing the application.
The authorization server can treat an application that registered via dynamic client registration as a confidential client. A malicious party cannot know the client secrets of all users and mount a large scale attack. If a particular client secret is compromised, access to that application instance can be disabled without impacting all other instances. Consequently, by using dynamic client registration in mobile applications, authorization servers do not have to compromise and can provide a secure setup with a good user experience.
Portals and API Management Systems
In this use case, administrators use a portal of some sort to register new applications that consume OAuth-protected APIs. Such a portal can be one of the offerings of an API gateway (e.g., Apigee). As part of the registration process, the portal or API gateway also needs to register the API consumer -- the application -- with the authorization server so that the application can obtain access tokens from the authorization server to be able to communicate with the APIs.
For such an integration to work, the authorization server needs to provide an interface for the portal or API gateway. The Curity Identity Server comes with a convenient admin REST API for this purpose, but dynamic client registration provides a standard API that most gateways support out of the box.
Open Ecosystem
Some ecosystems, like open banking, require that any third-party provider that fulfills certain requirements can join the ecosystem and integrate their applications with the services of that ecosystem. Consequently, the services or APIs are not publicly open but service providers restrict access to trusted third parties only. Clients then need to provide proof of accreditation, e.g., by presenting a credential form a trusted third-party authority.
Manual registration to set up the trust is often not an option as it hinders integration speed and is impractical. Instead, there should be a common protocol that allows for automatic onboarding, which dynamic client registration provides. Often, X.509 certificates or other signed assertions (such as a software statement) serve as proof that the third-party provider fulfills the requirements that the ecosystem set up. An application needs to provide this proof when registering as a client at one of the service providers.
Architectural Overview of Dynamic Client Registration
An authorization server can, optionally, restrict access to its client registration endpoint using OAuth. In this case, the client needs to provide an initial access token during the registration request. The details about whether or how an application needs to retrieve an initial access token for the registration request are vendor-specific. These specifics impact how the client communicates with the authorization server prior to the registration request. For this reason, make yourself familiar with the high-level overview of the possible architectures and flows before looking at the actual request/response of the protocol.
Deployment Patterns
To understand how to apply the dynamic client registration protocol, it is important to know the different configurations or deployment options. Some vendors may only offer open registration, while others may have a user interface for administrators to generate initial access tokens. If enabled, there are three ways to configure dynamic client registration in the Curity Identity Server (from the least to the most secure option).
- Open Registration: Dynamic client registration for any client without authentication. This is the most promiscuous setting and is typically suitable for testing or very open ecosystems. This case is very rare and this overview won't discuss it further in this overview.
- Client-authenticated Registration: Dynamic client registration for clients which have an initial access token that they obtained using the client credential flow. In this case, the authorization server only verifies the identity of the client, not the user.
- User-authenticated Registration: Dynamic client registration for clients which have an initial access token that they obtained after a user has authenticated. In this case, the authorization server identifies the client but only verifies the end user.
The two cases to understand more deeply are Client-authenticated Registration and User-authenticated Registration.
Client-authenticated Registration
Client-authenticated registration is, for example, useful in the API management use case mentioned above, where a portal registers clients at the authorization server.
In this case, an administrator can configure the portal with a client ID and client secret (or other credentials). When developers register a new application via the portal, the portal retrieves an initial access token on demand using the client credential flow by requesting the scope dcr. The portal can then register the application details at the authorization server with that access token. It can't use the access token for any other API call (limited via the scope).
Client-authenticated registration is also suitable for ecosystems that use X.509 certificates to establish trust. In this case, clients receive a certificate out of bounds, e.g. via an accreditation service. Certificate-based authentication is a standardized, widely supported client authentication method in OAuth. Clients can use their certificates to authenticate with an authorization server within the ecosystem to get the initial access token and register their details. Furthermore, clients can reuse their certificates across all authorization servers within the ecosystem, which provides a unified approach.
As a rule of thumb, when it comes to (publicly available) mobile applications you should avoid client-authenticated registration because you cannot securely distribute the client credentials required to authenticate the client for the initial access token. Consider user-authenticated registration instead.
There may be situations though, where users do not have an account or cannot create one using self-service sign-up methods as part of the authentication process, or there is no user to begin with. In certain cases, you can accept and minimize the risks associated with compiled credentials, for example, when the application is only available via an MDM system or similar that only a limited group of people can access. A case where you want to deploy client-authenticated registration for mobile applications is when preparing a phone for a new hire and installing an employee app before the user is (fully) onboarded.
User-authenticated Registration
User-authenticated registration is useful when distributing a platform-specific application, like a mobile or desktop client, to customers, partners, or a broad user base. In this setup, the application contains only a client ID to identify itself at the authorization server. The application triggers a flow like the code flow using its client ID. As part of such a flow, the authorization server identifies the application and authenticates the user. After the user authenticates, the authorization server issues an initial access token to the application. As with client-authenticated registration, the application can use this initial access token only to dynamically register itself.
Single Sign-On
When the user authenticates, the browser stores a single sign-on (SSO) cookie. This is important because, once registered, the application needs to get another access token for its ordinary API requests. At this point, just a few seconds after login, you typically want to avoid prompting the user again and SSO allows for that.
Initial Access Token
Whether the client authenticates or the user authenticates when registering, the client application first obtains an initial access token. It uses this token to register a specific instance. To limit this token's usage, the Curity Identity Server enforces a special scope called dcr. Other vendors supporting initial access tokens use similar scopes.
Registration
Unless dynamic client registration is open for any client, the client registration endpoint is protected using OAuth. This means that the client needs to present the initial access token during the registration request. Typically, this implies including the access token in the Authorization request header using the bearer authentication scheme (per RFC 6750).
The details of the request body depend on the characteristics of the deployment. In general, there are two ways to register a new client:
- The client registers as instances of an existing application where an existing client configuration functions as a sort of template for the dynamically registered one.
- The client registers as an entirely new application/client.
These two approaches often correspond to the first two primary use cases described above, but they need not.
Template Clients
Dynamic client registration introduces the concept of software, which refers to the application that implements the OAuth client. Each software has a unique identifier. The authorization server can use the software identifier to associate a dynamically registered client with an application.
This additional abstraction is necessary because with dynamic client registration, an application such as a mobile application may have multiple clients registered at an authorization server. All of those clients have common characteristics, though. Some deployments use software statements to communicate common characteristics (in a verifiable manner) to the authorization server.
In the Curity Identity Server, you can configure so-called template clients, which describe the common characteristics of multiple clients that belong to the same application, such as supported flows, redirect URIs, or authorized scopes. Each template client has an ID that corresponds to the software ID. Each instance of the template receives a unique client ID and a unique client secret.
Template clients are convenient because the registration request only needs to contain the id of the template to use. The result is a client based on that template. This greatly simplifies administration, as the authorization server only needs to maintain one template. This means that if the configuration of the template changes (e.g., authentication requirements, redirect URI(s), allowed scopes, etc.), then all dynamic clients based on that template client are immediately updated.
When registering instances of an application, as in the mobile application use case above, template clients can be very helpful since only the client ID and secret vary per installation.
Non-Template Clients
Non-template clients are not based on configured templates. As a consequence, the registration request needs to contain all of the parameters required to fully describe the client and its capability. If the client needs to provide unique or unknown properties, for example in a developer portal use case, use a non-template client.
Compliance and Best Practices
To align with security best practices and compliance requirements such as GDPR, you should implement policies for client metadata storage, revocation, and expiration. Some key recommendations include:
- Regularly review and revoke unused dynamically registered clients to prevent security risks.
- Ensure least privilege access by granting only the necessary scopes and permissions to registered clients.
- Implement monitoring and logging to track dynamic client registrations and detect suspicious activity.
- Enforce short-lived registration access tokens to reduce the risk of misuse.
Conclusion
This introduction explained an architectural overview of dynamic client registration (DCR). To learn more about DCR see the following resources to gain a deeper understanding, and to learn how to run DCR flows with the Curity Identity Server:
- Using Dynamic Client Registration
- Dynamic Client Registration Authentication Methods
- Dynamic Client Registration Management
- Dynamic Client Registration for mobile applications
- Dynamic Client Registration in the Curity Identity Server Documentation
With dynamic client registration you can better manage the security risks around distributing applications. To this end, the Curity Identity Server provides a templatized approach to dynamic client administration. Also, using the various authentication options for client registration, you can create a flexible system that doesn't expose your organization to vulnerabilities.
Jacob Ideskog
Identity Specialist and CTO at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
