Dynamic Clients

Dynamic Clients adhere to a specification called OAuth 2.0 Dynamic Client Registration (DCR) Protocol, or RFC-7591 for short. They are one of the types of clients the Curity Identity Server supports.

Similarly to Database Clients , Dynamic Clients are stored in Data Sources . They differ only in how they are managed, and to a much smaller degree, in what configuration settings they support.

The section below give a short description of the Dynamic Client Registration Protocol and in what scenarios it can be useful. For a full architecture overview, refer to the DCR Architecture page, and for an API reference, see DCR API .

Dynamic Client Registration Protocol - Motivation#

One of the primary uses of OpenID Connect metadata is to create a dynamic platform. An important part of that is the client or apps that will use the OAuth and OpenID provider to obtain tokens.

With the published metadata, clients can obtain information about endpoints and supported capabilities (i.e., flows or grant types). Even without discovering this information dynamically, it is very common to register new apps on the fly.

There are three primary use cases where this is needed:

1. When an app is installed by a user and the app instance needs an installation-specific client ID and secret.
2. When an API manager or developer portal wishes to create new apps that will consume APIs.
3. In an open environment where clients should be able to register at will.

For all of these cases, clients can dynamically register using the API defined in RFC-7591.

That specification is a superset of the OpenID Connect Dynamic Client Registration protocol. It allows apps to request a new client ID and secret which can then be used to obtain user authorization.

On top if initial registration, the Curity Identity Server also supports Dynamic Client Registration Management per RFC-7592 to allow for managing the client during its lifetime.

The first case comes up when an iOS, Android, and other kind of native app is installed on a user’s device. At that time, it will register itself to get a client ID and secret that is unique to that installation. This is important because any such credential that is compiled into and distributed with the app is not truly secret. It can be extracted from the application with relative ease.

By registering for an installation-specific client ID and secret instead, the app can be treated as a confidential client. Being able to keep a credential secret is a requirement imposed by the OAuth standard to issue a refresh token. Without this, the mobile app needs the user to re-authenticate every time its access token expired. This is a very poor User Experience (UX).

Consequently, non-confidential mobile clients are usually given a refresh token despite the security risks. By using DCR, this compromise does not need to be made.

In the second case, admins use a portal of some sort to register new apps that will consume APIs. This portal is usually provided by an API gateway product of some sort. In this case, the API consumer needs to be registered with the OAuth server, so that it can get its users logged in and obtain tokens from the OAuth server. Because token issuance is provided by Curity and not the gateway, the latter needs to register itself and get a client ID and secret that developers can use in their app. Curity’s admin REST API can be used for this purpose (and is actually preferable in many cases), but Dynamic Client Registration provides a standard API that most gateways support out of the box.

The Curity Identity Server supports these specifications and can be used to implement the first two use cases; open registration is currently unsupported. Instead, some form of identification — of either the user or the client — is required.

See the DCR API documentation for further information.