OpenID Connect Dynamic Client Registration

Open ID Connect enables clients (relying party) to verify the identity and obtain profile information of the end user based on the authentication performed by an authorization server, in an interoperable and REST-like manner. Client applications must be registered before they can login end-users with OpenID Connect or receive OAuth 2.0 access tokens. The following section provides information on how an OpenID Connect Relying party can dynamically register with the end user's OpenID provider.

How it works

To register a new client at the authorization server:

1. Client discovers the client registration endpoint. For more information on how to do this, see OpenID Connect Discovery Support. The registration endpoint URL discoverable via WebFinger. For more information on discovering the client registration endpoint, see OpenID Connect Discovery. 
2. Client sends an HTTP POST message to the client registration endpoint with and client metadata parameters that the client chooses to specify for itself during the registration. 
3. The authorization server assigns a unique client identifier (client ID) and optionally a client secret.
4. The authorization server associates the metadata given in the request with the issued client ID.

Sample Requests

To register, the client sends an HTTP POST message to the client registration endpoint. A sample request and response is shown below. 

POST /identity/connect/register
Content-Type: application/json
Accept: application/json
Host: server.example.com

{
    "redirect_uris": ["server.example.com"],
    "client_name": "application_1",
    "ext_param_owner": "application_owner",
    "grant_types": ["password"]
}

{
	"client_id": "s6BhdRkqt3",
	"client_secret":
	"ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
	"client_secret_expires_at": 1577858400,
	"redirect_uris":
	["server.example.com"],
	"client_name": "application_owner_application_1"
} 

{
"error": "invalid_redirect_uri",
"error_description": "One or more redirect_uri values are invalid"
} 

To de-provision itself on the authorization server, the client sends a HTTP DELETE request to the client configuration endpoint. 

DELETE /identity/register/s6BhdRkqt3 HTTP/1.1
Host: server.example.com