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:
For all of these cases, clients can dynamically register using the API defined in RFC 7591. This 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 Security Token Server also supports Dynamic Client Registration Management per RFC 7592, to allow for changing 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 Dynamic Client Registration, 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 Security Token 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. How this works is described in the following sections.