Dynamic Client Registration

AM supports dynamic registration as defined by RFC 7591, the OAuth 2.0 Dynamic Client Registration Protocol, and as defined by the the OpenID Connect Dynamic Client Registration 1.0 specification. The specifications describe how OAuth 2.0 and OpenID Connect clients can register:

Client Registration Methods

Without an access token, providing only their client metadata as a JSON resource.
AM generates client_id and client_secret values. AM ignores any values provided in the client metadata for these properties.
Providing either a self-signed or a CA-signed X.509 certificate as authentication (OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens internet-draft) and its client metadata as JSON.
By gaining authorization using an OAuth 2.0 access token, and with their client metadata.
The specification does not describe how the client obtains the access token. In AM, you can manually register an initial OAuth 2.0 client that obtains the access token on behalf of the client requesting registration.
You can use this method to provide a client with a specific client ID, and then allow the client to modify its metadata.
Note
The logo_uri, client_uri, and policy_uri parameters are only accepted during dynamic client registration if the access token contains the dynamic_client_registration special scope.
With client metadata that includes a software statement.
A software statement is a JWT that holds registration claims about the client, such as the issuer and the redirection URIs that it will register.
A software statement is issued by a software publisher. The software publisher encrypts and signs the claims in the software statement.
In AM, you store software publisher details as an agent profile. The software publisher profile identifies the issuer included in software statements, and holds information required to decrypt software statement JWTs and to verify their signatures. When the client presents a software statement as part of the dynamic registration data, AM uses the software publisher profile to determine whether it can trust the software statement.
The protocol specification does not describe how the client obtains the software statement JWT. AM expects the software publisher to construct the JWT according to the settings in its agent profile. Note, however, that AM ignores keys specified in JWT headers, such as jku and jwe.

To Configure AM for Dynamic Client Registration

Perform the following steps to configure AM for dynamic client registration:

Configure an authorization service.
For details, see "To Configure the OAuth 2.0 Provider Service".
Navigate to Realms > Realm > Services > OAuth2 Provider.
On the Client Dynamic Registration tab, consider configuring the following settings:
- To let clients register without an access token, enable Allow Open Dynamic Client Registration.
  If you enable this option, consider some form of rate limiting. Also consider requiring a software statement.
- To require that clients present a software statement upon registration, enable Require Software Statement for Dynamic Client Registration, and edit the Required Software Statement Attested Attributes list to include the claims that must be present in a valid software statement. In addition to the elements listed, the issuer (iss) must be specified in the software statement's claims, and the issuer value must match the Software publisher issuer value for a registered software publisher agent.
  As indicated in the protocol specification, AM rejects registration with an invalid software statement.
  If the issuer is compressing the JWT, note that by default, AM rejects JWTs that expand to a size larger than 32 KiB (32768 bytes). For more information, see "Controlling the Maximum Size of Compressed JWTs".
For additional details, see "Client Dynamic Registration".
(Optional) If the clients will authenticate using mTLS with CA-signed (PKI) certificates, configure AM to hold the certificates belonging to the certificate authorities you want the instance of AM to trust. For more information, see "Mutual TLS Using Public Key Infrastructure".
(Optional) If you enabled Require Software Statement for Dynamic Client Registration, then you must register a software publisher:
1. In the AM console under Realm > Applications > Agents > Software Publisher, add a new software publisher agent.
  If the publisher uses HMAC (symmetric) encryption for the software statement JWT, then the software publisher's password is also the symmetric key. This is called the Software publisher secret in the profile.
2. In the software publisher profile, configure the appropriate security settings.
  Important
  The Software publisher issuer value must match the iss value in claims of software statements issued by this publisher.
  If the publisher uses symmetric encryption, including HS256, HS384, and HS512, then the Software publisher secret must match the k value in the JWK.
  If you provide the JWK by URI rather than by value, AM must be able to access the JWK when processing registration requests.
(Optional) On the Advanced tab, in the Client Registration Scope Whitelist field, add the scopes clients can register with.

(Optional) Review the following dynamic client registration examples:

Open Dynamic Client Registration

The following example shows dynamic registration with the Allow Open Dynamic Client Registration option enabled (Realms > Realm Name > Services > OAuth2 Provider > Client Dynamic Registration).

The client registers with its metadata as the JSON body of an HTTP POST to the registration endpoint. When specifying client metadata, be sure to include a client_name property that holds the human-readable name presented to the resource owner during consent:

$ curl \
 --request POST \
 --header "Content-Type: application/json" \
 --data '{
 "redirect_uris": ["https://client.example.com:8443/callback"],
 "client_name#en": "My Client",
 "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "client_uri": "https://client.example.com/"
 }' \
 "https://openam.example.com:8443/openam/oauth2/register"
{
 "request_object_encryption_alg": "",
 "default_max_age": 1,
 "application_type": "web",
 "client_name#en": "My Client",
 "registration_client_uri": "https://openam.example.com:8443/openam/oauth2/register?client_id=2aeff083-83d7-4ba1-ab16-444ced02b535",
 "client_type": "Confidential",
 "userinfo_encrypted_response_alg": "",
 "registration_access_token": "4637ee46-51df-4901-af39-fec5c3a1054c",
 "client_id": "2aeff083-83d7-4ba1-ab16-444ced02b535",
 "token_endpoint_auth_method": "client_secret_basic",
 "userinfo_signed_response_alg": "",
 "public_key_selector": "x509",
 "authorization_code_lifetime": 0,
 "client_secret": "6efb5636-6537-4573-b05c-6031cc54af27",
 "user_info_response_format_selector": "JSON",
 "id_token_signed_response_alg": "HS256",
 "default_max_age_enabled": false,
 "subject_type": "public",
 "jwt_token_lifetime": 0,
 "id_token_encryption_enabled": false,
 "redirect_uris": ["https://client.example.com:8443/callback"],
 "client_name#ja-jpan-jp": "クライアント名",
 "id_token_encrypted_response_alg": "RSA1_5",
 "id_token_encrypted_response_enc": "A128CBC_HS256",
 "client_secret_expires_at": 0,
 "access_token_lifetime": 0,
 "refresh_token_lifetime": 0,
 "request_object_signing_alg": "",
 "response_types": ["code"]
 }

Tip

OpenID Connect clients must ensure that the following information is present in the JSON:

The openid scope. For example, "scopes": ["profile", "openid"].
The id_token response type. For example, "response_types": ["code", "id_token code"].

Dynamic Client Registration with Mutual TLS Authentication

The following example shows the different properties required for clients using mTLS for authentication depending on the type of certificate presented:

Clients using CA-signed X.509 certificates (PKI)

To use CA-signed certificates (PKI), you must configure AM to hold the certificates belonging to the certificate authorities you want the instance of AM to trust. For more information, see "Mutual TLS Using Public Key Infrastructure".

Include the following properties as part of the client metadata:

token_endpoint_auth_method, which must be set to tls_client_auth.
tls_client_auth_subject_dn, which must be set to the distinguished name as it appears in the subject field of the certificate. For example, CN=myOauth2Client.

Clients using self-signed X.509 certificates

Clients authenticating using self-signed certificates can provide their certificates for validation in one of the following ways:

As a JWKS.
In this scenario, the client provides as part of its metadata the JWKS containing its certificate(s).
Include the following properties as part of the client metadata:
- token_endpoint_auth_method, which must be set to self_signed_tls_client_auth.
- A JWKS, configured as per RFC 7517, which includes certificate information.
As a JWKS URI, which AM will check periodically to retrieve the certificates from.
In this scenario, the client provides as part of its metadata the URI from where AM will retrieve the certificate(s) for validation.
Include the following properties as part of the client metadata:
- token_endpoint_auth_method, which must be set to self_signed_tls_client_auth.
- jwks_uri, which must be set to the URI from where AM will retrieve the certificates. For example, https://www.example.com/mysecureapps/certs.
As an X.509 certificate.
In this scenario, the client provides as part of its metadata a single X.509 certificate in PEM format.
Include the following properties as part of the client metadata:
- token_endpoint_auth_method, which must be set to self_signed_tls_client_auth.
- tls_client_auth_x509_cert, which must be set to an X.509 certificate in PEM format. You can choose to include or exclude the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- labels.

The following example shows dynamic registration of a client that will provide their self-signed ECDSA P-256 certificate in a JWKS:

$ curl \
 --request POST \
 --header "Content-Type: application/json" \
 --data '{
    "jwks": {
        "keys": [{
            "kty": "EC",
            "crv": "P-256",
            "x": "9BmRru-6AYQ8U_9tUFhMGVG-BvC4vRthzLJTntfSdBA",
            "y": "MqPzVSeVNzzgcR-zZeLGog3GJ4d-doRE9eiGkCKrB48",
            "kid": "a4:68:90:1c:f6:c1:43:c0",
            "x5c": [
                "MIIBZTCCAQugAwIB.....xgASSpAQC83FVBawjmbv6k4CN95G8zHsA=="
            ]
        }]
    },
    "client_type": "Confidential",
    "grant_types": ["authorization_code", "client_credentials"],
    "response_types": ["code", "token"],
    "redirect_uris": ["https://client.example.com:8443/callback"],
    "token_endpoint_auth_method": "self_signed_tls_client_auth",
    "tls_client_auth_subject_dn": "CN=myOauth2Client",
    "tls_client_certificate_bound_access_tokens": true
}' \
 "https://openam.example.com:8443/openam/oauth2/register"
{
  "request_object_encryption_alg": "",
  "default_max_age": 1,
  "jwks": {
    "keys": [
      {
        "kty": "EC",
        "crv": "P-256",
        "x": "9BmRru-6AYQ8U_9tUFhMGVG-BvC4vRthzLJTntfSdBA",
        "y": "MqPzVSeVNzzgcR-zZeLGog3GJ4d-doRE9eiGkCKrB48",
        "kid": "a4:68:90:1c:f6:c1:43:c0",
        "x5c": [
          "MIIBZTCCAQugAwIB.....xgASSpAQC83FVBawjmbv6k4CN95G8zHsA=="
        ]
      }
    ]
  },
  "application_type": "web",
  "tls_client_auth_subject_dn": "CN=myOauth2Client",
  "registration_client_uri": "https://openam.example.com:8443/openam/oauth2/register?client_id=83635999-2794-4fcd-b6b3-67e2d86c1952",
  "client_type": "Confidential",
  "userinfo_encrypted_response_alg": "",
  "registration_access_token": "tu4KR0jO3iGn0ubOOY0YCSfyPmk",
  "client_id": "83635999-2794-4fcd-b6b3-67e2d86c1952",
  "token_endpoint_auth_method": "self_signed_tls_client_auth",
  "userinfo_signed_response_alg": "",
  "public_key_selector": "jwks",
...
}

Note that the example sets tls_client_certificate_bound_access_tokens to true to let the client obtain certificate-bound access tokens. For more information, see "Certificate-Bound Proof-of-Possession".

Tip

OpenID Connect clients must ensure that the following information is present in the JSON:

The openid scope. For example, "scopes": ["profile", "openid"].
The id_token response type. For example, "response_types": ["code", "id_token code"].

Dynamic Client Registration With Access Token

The following example shows dynamic registration with default OAuth 2.0 provider service settings, providing an access token issued to a statically registered client.

In this example the statically registered client has the following profile settings:

Client ID: masterClient
Client secret: password
Scope(s): dynamic_client_registration

Prior to registration, obtain an access token:

$ curl \
--request POST \
--user "masterClient:password" \
--data "grant_type=password&username=amadmin&password=password&scope=dynamic_client_registration" \
https://openam.example.com:8443/openam/oauth2/realms/root/access_token
{
   "access_token":"5e7d1019-b752-43f1-af97-0d6fe2753105",
   "scope":"dynamic_client_registration",
   "token_type":"Bearer",
   "expires_in":3599
}

The client registers with its metadata, providing the access token. When specifying client metadata, be sure to include a client_name property that holds the human-readable name presented to the resource owner during consent:

$ curl \
--request POST \
--header "Content-Type: application/json" \
--header "Authorization: Bearer 5e7d1019-b752-43f1-af97-0d6fe2753105" \
--data '{
    "redirect_uris": ["https://client.example.com/callback"],
    "client_name#en": "My Client",
    "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
    "client_uri": "https://client.example.com/"
}" \
"https://openam.example.com:8443/openam/oauth2/register"
{
     "request_object_encryption_alg": "",
     "default_max_age": 1,
     "application_type": "web",
     "client_name#en": "My Client",
     "registration_client_uri": "https://openam.example.com:8443/openam/oauth2/register?client_id=d58ba00b-da55-4fa3-9d2a-afe197207be5",
     "client_type": "Confidential",
     "userinfo_encrypted_response_alg": "",
     "registration_access_token": "5e7d1019-b752-43f1-af97-0d6fe2753105",
     "client_id": "d58ba00b-da55-4fa3-9d2a-afe197207be5",
     "token_endpoint_auth_method": "client_secret_basic",
     "userinfo_signed_response_alg": "",
     "public_key_selector": "x509",
     "authorization_code_lifetime": 0,
     "client_secret": "4da529de-3a18-4fb7-a0a9-07e05a394aa4",
     "user_info_response_format_selector": "JSON",
     "id_token_signed_response_alg": "HS256",
     "default_max_age_enabled": false,
     "subject_type": "public",
     "jwt_token_lifetime": 0,
     "id_token_encryption_enabled": false,
     "redirect_uris": ["https://client.example.com:8443/callback"],
     "client_name#ja-jpan-jp": "クライアント名",
     "id_token_encrypted_response_alg": "RSA1_5",
     "id_token_encrypted_response_enc": "A128CBC_HS256",
     "client_secret_expires_at": 0,
     "access_token_lifetime": 0,
     "refresh_token_lifetime": 0,
     "request_object_signing_alg": "",
     "response_types": ["code"]
 }

Tip

OpenID Connect clients must ensure that the following information is present in the JSON:

The openid scope. For example, "scopes": ["profile", "openid"].
The id_token response type. For example, "response_types": ["code", "id_token code"].

Dynamic Client Registration With Software Statement

The following example extends Dynamic Client Registration With Access Token to demonstrate dynamic registration with a software statement.

In this example, the software publisher has the following profile settings:

Name

My Software Publisher

Software publisher secret

secret

Software publisher issuer

https://client.example.com

Software statement signing Algorithm

HS256

Public key selector

JWKs

Json Web Key

{"keys": [{"kty": "oct", "k": "secret", "alg":"HS256"}]}

Notice that the value is a key set rather than a single key.

In this example, the software statement JWT is as shown in the following listing, with lines folded for legibility:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJpc3MiOiJodHRwczovL2NsaWVudC5leGFtcGxlLmNvbSIsImlhdCI6MTUwNjY3MTg1MSwiZX
hwIjoxNTM4MjA3ODUxLCJhdWQiOiJvcGVuYW0uZXhhbXBsZS5jb20iLCJzdWIiOiI0TlJCMS0w
WFpBQlpJOUU2LTVTTTNSIiwicmVkaXJlY3RfdXJpcyI6WyJodHRwczovL2NsaWVudC5leGFtcG
xlLmNvbS9jYWxsYmFjayJdfQ.
IOxZaWTOzSPkEkrXC9nj8RDrpulzzMuZ-4R7_Ol_jhw

This corresponds to the HS256 encrypted and signed JWT with the following claims payload.:

{
  "iss": "https://client.example.com",
  "iat": 1506671851,
  "exp": 1538207851,
  "aud": "openam.example.com",
  "sub": "4NRB1-0XZABZI9E6-5SM3R",
  "redirect_uris": [
    "https://client.example.com/callback"
  ]
}

Prior to registration, obtain an access token:

$  curl --request POST \
--data "grant_type=password" \
--data "username=demo" \
--data "password=Ch4ng31t" \
--data "scope=dynamic_client_registration" \
--data "client_id=masterClient" \
--data "client_secret=password" \
"https://openam.example.com:8443/openam/oauth2/realms/root/access_token"
{
   "access_token":"06bfc193-1f7b-49a1-9926-ffe19e2f5f70",
   "scope":"dynamic_client_registration",
   "token_type":"Bearer",
   "expires_in":3599
}

The client registers with its metadata that includes the software statement, providing the access token. When specifying client metadata, be sure to include a client_name property that holds the human-readable name presented to the resource owner during consent:

$ curl \
 --request POST \
 --header "Content-Type: application/json" \
 --header "Authorization: Bearer 06bfc193-1f7b-49a1-9926-ffe19e2f5f70" \
 --data '{
 "redirect_uris": ["https://client.example.com:8443/callback"],
 "client_name#en": "My Client",
 "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "client_uri": "https://client.example.com/",
 "software_statement": "eyJ0eXAiOiJKV1QiLCJ6W....9nj8RDrpulzzMuZ-4R7_Ol_jhw"
 }' \
 "https://openam.example.com:8443/openam/oauth2/register"
{
 "request_object_encryption_alg": "",
 "default_max_age": 1,
 "application_type": "web",
 "client_name#en": "My Client",
 "registration_client_uri": "https://openam.example.com:8443/openam/oauth2/register?client_id=086658c1-0517-4667-bc2d-6786224eb126",
 "client_type": "Confidential",
 "userinfo_encrypted_response_alg": "",
 "registration_access_token": "06bfc193-1f7b-49a1-9926-ffe19e2f5f70",
 "client_id": "086658c1-0517-4667-bc2d-6786224eb126",
 "token_endpoint_auth_method": "client_secret_basic",
 "userinfo_signed_response_alg": "",
 "software_statement": "eyJ0eXAiOiJKV1QiLCJ6W....9nj8RDrpulzzMuZ-4R7_Ol_jhw",
 "public_key_selector": "x509",
 "authorization_code_lifetime": 0,
 "client_secret": "272e26a4-b4ea-4033-bfd3-8b1be2c9aa22",
 "user_info_response_format_selector": "JSON",
 "id_token_signed_response_alg": "HS256",
 "default_max_age_enabled": false,
 "subject_type": "public",
 "jwt_token_lifetime": 0,
 "id_token_encryption_enabled": false,
 "redirect_uris": ["https://client.example.com:8443/callback"],
 "client_name#ja-jpan-jp": "クライアント名",
 "id_token_encrypted_response_alg": "RSA1_5",
 "id_token_encrypted_response_enc": "A128CBC_HS256",
 "client_secret_expires_at": 0,
 "access_token_lifetime": 0,
 "refresh_token_lifetime": 0,
 "request_object_signing_alg": "",
 "response_types": ["code"]
}

Tip

OpenID Connect clients must ensure that the following information is present in the JSON:

The openid scope. For example, "scopes": ["profile", "openid"].
The id_token response type. For example, "response_types": ["code", "id_token code"].

Note

AM returns an error when a client tries to register with an unsupported signing or encryption algorithm as part of its configuration.

For example, it will return an error if there is a typo in an algorithm, or if a public client tries to send a symmetric signing or encryption algorithm as part of its configuration: these algorithms are derived from the client's secret, which public clients do not have.

Dynamic Client Registration Management

AM lets clients manage their information dynamically, as per RFC 7592 OAuth 2.0 Dynamic Client Registration Management Protocol and OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1. This RFC is an extension of the Dynamic Client Registration Protocol (RFC 7591).

Note that, during dynamic client registration, AM supplies clients with the following information:

registration_client_uri. The FQDN of the client configuration endpoint the client can use to update their data. This endpoint always contains the client ID as a query parameter.
registration_access_token. The token clients must use to authenticate to the client configuration endpoint.

Clients must store this information, since it is mandatory to read, update, and modify their profile information.

To Configure Client Dynamic Registration Management

Configure AM for dynamic client registration.
For more information, see "To Configure AM for Dynamic Client Registration".
Log in to the AM console as an administrative user, such as amAdmin.
Go to Realms > Realm Name > Services > OAuth2 Provider > Client Dynamic Registration, and ensure that Generate Registration Access Tokens is enabled.
Save your changes, if required.

(Optional) Review the following examples:

Client Read Request

Clients can use the read request to retrieve their current configuration from AM.

In this example, a client dynamically registered using the following command:

$ curl \
 --request POST \
 --header "Content-Type: application/json" \
 --data '{
 "redirect_uris": ["https://client.example.com:8443/callback"],
 "client_name#en": "My Client",
 "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "client_uri": "https://client.example.com/"
 }' \
 "https://openam.example.com:8443/openam/oauth2/register"

Among the returned information, the OAuth 2.0/OpenID Connect provider supplied the client with the following data:

...
"registration_client_uri":"https://openam.example.com:8443/openam/oauth2/register?client_id=77f296b3-5293-4219-981d-128322c1e173",
"registration_access_token":"o5IlBXOxC7RGPTIe8is_zzz6Yqg",
...

To request the information stored in its client profile, clients perform an HTTP GET request to the client registration endpoint. Use the registration token to authenticate to the endpoint by sending the token as an authorization bearer header. For example:

$ curl \
--request GET \
--header "Authorization: Bearer o5IlBXOxC7RGPTIe8is_zzz6Yqg" \
"https://openam.example.com:8443/openam/oauth2/register?client_id=77f296b3-5293-4219-981d-128322c1e173"
{
   "request_object_encryption_alg":"",
   "default_max_age":1,
   "application_type":"web",
   "client_name#en":"My Client",
   "userinfo_encrypted_response_enc":"A128CBC_HS256",
   "client_type":"Confidential",
   "userinfo_encrypted_response_alg":"",
   "token_endpoint_auth_method":"client_secret_basic",
   "userinfo_signed_response_alg":"",
   "client_id":"77f296b3-5293-4219-981d-128322c1e173",
   "public_key_selector":"x509",
   "client_secret":"vXxY3HJ7_...84qfRQHYW3QbZfDSXieAgIVa2tg",
   ....
}

If the OAuth 2.0/OpenID Connect provider is configured for a subrealm rather than the Top Level Realm, you must specify it in the endpoint. For example, if the provider is configured for the /customers realm, then use /oauth2/realms/root/realms/customers/register.

The server does not return the registration_client_uri nor the registration_access_token attributes.

Client Update Request

Clients can use the update request to modify their client profile while retaining their client ID.

In this example, a client dynamically registered using the following command:

$ curl \
 --request POST \
 --header "Content-Type: application/json" \
 --data '{
 "redirect_uris": ["https://client.example.com:8443/callback"],
 "client_name#en": "My Client",
 "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "client_uri": "https://client.example.com/"
 }' \
 "https://openam.example.com:8443/openam/oauth2/register"

Among the returned information, the OAuth 2.0/OpenID Connect provider supplied the client with the following data:

...
"registration_client_uri":"https://openam.example.com:8443/openam/oauth2/register?client_id=77f296b3-5293-4219-981d-128322c1e173",
"registration_access_token":"o5IlBXOxC7RGPTIe8is_zzz6Yqg",
"grant_types":["authorization_code"],
...

The client performs a read request to the OAuth 2.0/OpenID Connect provider to retrieve its current configuration.

When updating the client's metadata, AM:

Resets to the default value any client setting not sent with the update request.
Returns a new registration access token to the client.
Rejects requests where the client secret does not match with the one already registered.
Rejects requests containing the following metadata (as per RFC 7592):
- registration_access_token
- registration_client_uri
- client_secret_expires_at
- client_id_issued_at

To update the metadata, clients make an HTTP PUT request to the registration endpoint. The request contains all the metadata returned from the read request minus the information that, as specified by the spec, should not be sent. Use the registration token to authenticate to the endpoint by sending the token as an authorization bearer header.

In the following example, the OAuth 2.0 client sends the required metadata to AM, updating its grant types to "authorization code","implicit":

$ curl \
--request PUT \
--header "Authorization: Bearer o5IlBXOxC7RGPTIe8is_zzz6Yqg" \
--data '{
    "request_object_encryption_alg":"",
    "default_max_age":1,
    "application_type":"web",
    "client_name#en":"My Client",
    "userinfo_encrypted_response_enc":"",
    "client_type":"Confidential",
    "userinfo_encrypted_response_alg":"",
    "token_endpoint_auth_method":"client_secret_basic",
    "userinfo_signed_response_alg":"",
    "client_id":"77f296b3-5293-4219-981d-128322c1e173",
    "public_key_selector":"x509",
    "scope":"write",
    "authorization_code_lifetime":0,
    "client_secret":"vXxY3HJ7_...84qfRQHYW3QbZfDSXieAgIVa2tg",
    "user_info_response_format_selector":"JSON",
    "tls_client_certificate_bound_access_tokens":false,
    "id_token_signed_response_alg":"RS256",
    "default_max_age_enabled":false,
    "subject_type":"public",
    "grant_types":["authorization_code","implicit"],
    "jwt_token_lifetime":0,
    "id_token_encryption_enabled":false,
    "redirect_uris":["https://client.example.com:8443/callback"],
    "client_name#ja-jpan-jp":"クライアント名",
    "id_token_encrypted_response_alg":"RSA-OAEP-256",
    "id_token_encrypted_response_enc":"A128CBC-HS256",
    "access_token_lifetime":0,
    "refresh_token_lifetime":0,
    "scopes":["write"],
    "request_object_signing_alg":"",
    "response_types":["code"]
}" \
"https://openam.example.com:8443/openam/realms/root/oauth2/register?client_id=77f296b3-5293-4219-981d-128322c1e173"
{
    "request_object_encryption_alg":"",
    "default_max_age":1,
    "application_type":"web",
    "client_name#en":"My Client",
    "userinfo_encrypted_response_enc":"",
    "client_type":"Confidential",
    "userinfo_encrypted_response_alg":"",
    "registration_access_token":"NrvX2bqydMgr...EGI32YuvyrkxDpD_xJVHtHo6fXQ",
    "client_id":"77f296b3-5293-4219-981d-128322c1e173",
    ...
}

If the OAuth 2.0/OpenID Connect provider is configured for a subrealm rather than the Top Level Realm, you must specify it in the endpoint. For example, if the provider is configured for the /customers realm, then use /oauth2/realms/root/realms/customers/register.

When successful, AM returns an HTTP 200 message and the profile data with the changes. Note that the registration access token has changed; the client must store the new token securely.

Client Deletion Request

Clients can use the delete request to deprovision themselves from AM.

In this example, a client dynamically registered using the following command:

$ curl \
 --request POST \
 --header "Content-Type: application/json" \
 --data '{
 "redirect_uris": ["https://client.example.com:8443/callback"],
 "client_name#en": "My Client",
 "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "client_uri": "https://client.example.com/"
 }' \
 "https://openam.example.com:8443/openam/oauth2/register"

Among the returned information, the OAuth 2.0/OpenID Connect provider supplied the client with the following data:

...
"registration_client_uri":"https://openam.example.com:8443/openam/oauth2/register?client_id=77f296b3-5293-4219-981d-128322c1e173",
"registration_access_token":"o5IlBXOxC7RGPTIe8is_zzz6Yqg",
...

To deprovision themselves, clients send an HTTP DELETE request to the client registration endpoint. Use the registration token to authenticate to the endpoint by sending the token as an authorization bearer header. For example:

$ curl \
--request DELETE \
--header "Authorization: Bearer o5IlBXOxC7RGPTIe8is_zzz6Yqg" \
"https://openam.example.com:8443/openam/oauth2/register?client_id=77f296b3-5293-4219-981d-128322c1e173"

If the OAuth 2.0/OpenID Connect provider is configured for a subrealm rather than the Top Level Realm, you must specify it in the endpoint. For example, if the provider is configured for the /customers realm, then use /oauth2/realms/root/realms/customers/register.

If the deprovision is successful, AM returns an HTTP 204 No Content message. AM does not invalidate the authorization grants or active tokens associated with the client, which will expire in time. However, new requests to OAuth 2.0 endpoints will fail since the client no longer exists.

Dynamic Client Registration

Note

Important

Tip

Tip

Tip

Tip

Note

Dynamic Client Registration Management