Client Registration

Set this field if you have configured an OAuth 2.0 client group.

Specify whether the client profile is active for use or inactive.

Specify the client secret as described by RFC 6749 in the section, Client Password.

For OAuth 2.0/OpenID Connect 1.0 clients, AM uses the client password as the client shared secret key when signing the contents of the request parameter with HMAC-based algorithms, such as HS256.

Specify the client type.

Confidential clients can maintain the confidentiality of their credentials, such as a web application running on a server where its credentials are protected. Public clients run the risk of exposing their passwords to a host or user agent, such as a JavaScript client running in a browser.

Specify whether AM allows the use of wildcards (* characters) in the redirection URI port to match one or more ports.

The URL configured in the redirection URI must be either localhost, 127.0.01, or ::1. For example, http://localhost:*/, https://127.0.0.1:80*/, or https://[::1]:*443/.

Enable this setting, for example, for desktop apps that start a web server on a random free port during the OAuth 2.0 flow.

Specify client redirection endpoint URIs as described by RFC 6749 in the section, Redirection Endpoint. AM's OAuth 2.0 authorization service redirects the resource owner's user-agent back to this endpoint during the authorization code grant process. If your client has more than one redirection URI, then it must specify the redirection URI to use in the authorization request.

Redirection URI values must NOT contain a fragment (#) and must be an exact match. Wildcards are only considered special characters for ports when the Allow wildcard ports in redirection URIs option is enabled.

OpenID Connect clients require redirection URIs.

Specify scopes that are to be presented to the resource owner when the resource owner is asked to authorize client access to protected resources.

The openid scope is required for OpenID Connect clients. It indicates that the client is making an OpenID Connect request to the authorization server.

Scopes can be entered as simple strings, such as openid, read, email, profile, or as a pipe-separated string in the format: scope|locale|localized description. For example, read|en|Permission to view email messages.

Locale strings have the format: language_country_variant. For example, en, en_GB, or en_US_WIN. If the locale and pipe is omitted, the localized description is displayed to all users having undefined locales. If the localized description is omitted, nothing is displayed to all users. For example, a scope of read| would allow the client to use the read scope but would not display it to the user when requested.

AM reserves special scopes to let resource servers introspect tokens issued to other clients. For more information, see "Special Scopes".

For more information about scopes and default scopes, and how AM uses them, see About Scopes.

Scopes that AM uses when the client does not request any during a grant flow.

Specify scopes in scope or scope|locale|localized description format.

Scopes defined in this property take the same format as those defined in Scope(s).

For more information about scopes and default scopes, and how AM uses them, see About Scopes.

Specify a human-readable name for the client.

Specify the time in seconds for an authorization code to be valid. If this field is set to zero, the authorization code lifetime of the OAuth2 provider is used.

Default: 0

Specify the time in seconds for a refresh token to be valid. If this field is set to zero, the refresh token lifetime of the OAuth2 provider is used. If the field is set to -1, the token will never expire.

Default: 0

Specify the time in seconds for an access token to be valid. If this field is set to zero, the access token lifetime of the OAuth2 provider is used.

Default: 0

Specify the authentication level that will be set for tokens created as a result of token exchange when the subject token does not have an authentication level to begin with. For example, when exchanging an ID token for an access token.

Default: 0

Specify a client name to display to the resource owner when the resource owner is asked to authorize client access to protected resources. Valid formats include name or locale|localized name .

The Display name can be entered as a single string or as a pipe-separated string for locale and localized name, for example, en|My Example Company.

Locale strings have the format:language_ country_ variant. For example, en, en_GB, or en_US_WIN. If the locale is omitted, the name is displayed to all users having undefined locales.

Specify a client description to display to the resource owner when the resource owner is asked to authorize client access to protected resources. Valid formats include description or locale|localized description.

The Display description can be entered as a single string or as a pipe-separated string for locale and localized name, for example, en|The company intranet is requesting the following access permission.

Locale strings have the format:language_ country_ variant. For example, en, en_GB, or en_US_WIN. If the locale is omitted, the name is displayed to all users having undefined locales.

Specify the origin URLs that the client allows to make cross-origin resource sharing (CORS) requests to AM.

For example, you might add the URL of a resource server being protected by an app that uses the ForgeRock SDKs, so that it can access the OAuth 2.0 endpoints from a different domain than AM.

Wildcards are not supported; each value should be an exact match for the origin of the CORS request.

The global CORS service collects the value of this property from each OAuth 2.0 client, and combines it with its own configuration.

Specify request_uri values that a dynamic client would pre-register.

URIs must be pre-registered in this field before the client can request them in the request_uri parameter.

Specify the set of OAuth 2.0 grant flows allowed for this client. The following flows are available:

When registering clients dynamically, if no grant types are specified in the registration request, then the default Authorization Code grant type is assumed, and configured in the client.

Any grant types selected in a client must also be enabled in the OAuth 2.0 provider service. See "OAuth2 Provider" .

Default: Authorization Code

Specify the response types that the client uses. The response type value specifies the flow that determine how the ID token and access token are returned to the client. For more information, see OAuth 2.0 Multiple Response Type Encoding Practices.

Configure this field only if the client uses OAuth 2.0 / OpenID Connect grant flows that interact with the /oauth2/authorize endpoint.

The following response types are available:

Specify the email addresses of users who administer the client.

Specify the authentication method with which a client authenticates to AM (as an authorization server) at the token endpoint. The authentication method applies to OIDC requests with scope openid.

For more information, see OAuth 2.0 Client Authentication, and Client Authentication in the OpenID Connect Core 1.0 incorporating errata set 1 specification.

Specify the host component of this URI, which is used in the computation of pairwise subject identifiers.

Specify the subject identifier type, which is a locally unique identifier that will be consumed by the client. Select one of two options:

Specify the registration_access_token value that you provide when registering the client, and then subsequently when reading or updating the client profile.

Specify the URI containing further information about this client. The URI is displayed as a link in user-facing pages, such as consent pages.

The URI can be made locale-specific by specifying a pipe-separated string in the format: URI|locale. For example, https://www.example.es:8443/aplicacion/informacion.html|es

Specify the URI of a logo for the client. The logo is displayed in user-facing pages, such as consent pages.

The logo can be made locale-specific by specifying a pipe-separated string in the format: URI|locale. For example, https://www.example.es:8443/aplicacion/imagen.png|es

Specify the URI containing the client's privacy policy documentation. The URI is displayed as a link in user-facing pages, such as consent pages.

The URI can be made locale-specific by specifying a pipe-separated string in the format: URI|locale. For example, https://www.example.es:8443/aplicacion/legal.html|es

Enable the implied consent feature. When enabled, the resource owner will not be asked for consent during authorization flows. The OAuth2 Provider must also be configured to allow clients to skip consent.

Enable OAuth 2.0 mix-up mitigation on the authorization server side.

Enable this setting only if this OAuth 2.0 client supports the OAuth 2.0 Mix-Up Mitigation draft, otherwise AM will fail to validate access token requests received from this client.

Specify one or more claim name translations that will override those specified for the authentication session. Claims are values that are presented to the user to inform them what data is being made available to the client.

Claims can be in entered as simple strings, such as name, email, profile, or sub, or as a pipe-separated string in the format: scope|locale|localized description. For example, name|en|Full name of user.

Locale strings have the format:language_ country_ variant. For example, en, en_GB, or en_US_WIN. If the locale and pipe is omitted, the localized description is displayed to all users having undefined locales. If the localized description is omitted, nothing is displayed to all users. For example, a claim of name| would allow the client to use the name claim but would not display it to the user when requested.

If a value is not given, the value is computed from the OAuth2 provider.

Specify one or more allowable URIs to which the user-agent can be redirected to after the client logout process.

Specify the relying party (client) URI to which the OpenID Connect Provider sends session changed notification messages using the HTML 5 postMessage API.

Specify the maximum time in seconds that a user can be authenticated. If the user last authenticated earlier than this value, then the user must be authenticated again. If specified, the request parameter max_age overrides this setting.

Minimum value: 1.

Default: 600

Enable the default max age feature.

Default Authentication Context Class Reference values.

Specify strings that will be requested as Voluntary Claims by default in all incoming requests.

Values specified in the acr_values request parameter or an individual acr claim request override these default values.

The time, in seconds, for a JWT to be valid. If this field is set to zero, the JWT token lifetime of the OAuth2 provider is used.

Default: 0

The URL to which AM sends the logout token during back-channel logout.

This URL can use the http or the https scheme, and may contain a port, a path, or query parameters, depending on the implementation of the relying party. For example, https://my-rp.example.com:443/logout.

For more information, see "Informing Relying Parties that a Session has Expired".

Specify whether to add the session ID (sid) to the logout token. The session ID identifies the relying party's session with the provider.

For more information, see "Informing Relying Parties that a Session has Expired".

Specify the URI that contains the client's public keys in JSON web key format.

When the client authenticates to AM using the private_key_jwt method, AM checks this field to find the public key to validate the JWT.

Specify the amount of time, in milliseconds, that the content of the JWKs' URI is cached for before being refreshed. Caching the content avoids fetching it for every token encryption or validation.

Default: 3600000

Specify the amount of time, in milliseconds, that AM waits before fetching the URI's content again when a key ID (kid) is not in the JWK set already cached.

For example, if a request comes in with a kid that is not in the cached JWKs, AM checks the value of JWKs' URI content cache miss cache time. If the amount of time specified in this property has already passed since the last time AM fetched the JWKs, AM fetches them again. Otherwise, the request is rejected.

Use this property as a rate limit to prevent denial-of-service attacks against the URI.

Default: 60000

Specify the JWS algorithm that must be used for signing JWTs used to authenticate the client at the Token Endpoint.

JWTs that are not signed with the selected algorithm in token requests from the client using the private_key_jwt or client_secret_jwt authentication methods will be rejected.

Default: RS256

Raw JSON web key value containing the client's public keys.

Specify the signing algorithm that the ID token must be signed with.

Enable ID token encryption using the specified ID token encryption algorithm.

Specify the algorithm that the ID token must be encrypted with.

Default value: RSA1_5 (RSAES-PKCS1-V1_5).

Specify the method that the ID token must be encrypted with.

Default value: A128CBC-HS256.

Specify the Base64-encoded public key for encrypting ID tokens.

Specify the base64-encoded X509 certificate in PEM format. The certificate is never used during the signing process, but is used to obtain the client's JWT bearer public key. The client uses the private key to sign client authentication and access token request JWTs, while AM uses the public key for verification.

The following is an example of the certificate:

-----BEGIN CERTIFICATE-----
MIIDETCCAfmgAwIBAgIEU8SXLj.....
-----END CERTIFICATE-----

You can generate a new key pair alias by using the Java keytool command. Follow the steps in "To Create Key Aliases in an Existing Keystore".

$ keytool \
-list \
-alias myAlias \
-rfc \
-storetype JCEKS \
-keystore myKeystore.jceks \
-keypass myKeypass \
-storepass myStorepass

Alias name: myAlias
Creation date: Oct 27, 2020
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
-----BEGIN CERTIFICATE-----
MIIDETCCAfmgAwIBAgIEU8SXLj.....
-----END CERTIFICATE-----

For more information, see "Authenticating Clients Using JWT Profiles".

Specify the base64-encoded X.509 certificate in PEM format that clients can use to authenticate to the access_token endpoint during mutual TLS authentication.

Only applies when clients use self-signed certificates to authenticate.

For more information, see "Mutual TLS Using Self-Signed X.509 Certificates"

Specify the distinguished name that must exactly match the subject field in the client certificate used for mutual TLS authentication. For example, CN=myOauth2Client.

Only applies when clients use CA-signed certificates to authenticate.

For more information, see "Mutual TLS Using Public Key Infrastructure".

Specify that access tokens issued to this client should be bound to the X.509 certificate it uses to authenticate to the access_token endpoint.

If enabled, AM adds a confirmation key labeled x5t#S256 to all access tokens. The confirmation key contains the SHA-256 hash of the client's certificate.

For more information, see "Certificate-Bound Proof-of-Possession"

Select the format of the public keys for JWT profile client authentication, ID token encryption, and mTLS self-signed certificate authentication. Valid formats are:

Default: JWKs_URI

Specify the output format from the UserInfo endpoint.

The supported output formats are as follows:

For more information on the output format of the UserInfo Response, see Successful UserInfo Response in the OpenID Connect Core 1.0 incorporating errata set 1 specification.

Default: User info JSON response format.

Specify the JSON Web Signature (JWS) algorithm for signing UserInfo Responses. If specified, the response will be JSON Web Token (JWT) serialized, and signed using JWS.

The default, if omitted, is for the UserInfo Response to return the claims as a UTF-8-encoded JSON object using the application/json content type.

Specify the JSON Web Encryption (JWE) algorithm for encrypting UserInfo Responses.

If both signing and encryption are requested, the response will be signed then encrypted, with the result being a nested JWT.

The default, if omitted, is that no encryption is performed.

Specify the JWE encryption method for encrypting UserInfo Responses. If specified, you must also specify an encryption algorithm in the User info encrypted response algorithm property.

AM supports the following encryption methods:

Default: A128CBC-HS256

Specify the JWS algorithm for signing the request parameter.

Must match one of the values configured in the Request parameter Signing Algorithms supported property of the OAuth2 Provider service. See "Advanced OpenID Connect" .

Specify the algorithm for encrypting the request parameter.

Must match one of the values configured in the Request parameter Encryption Algorithms supported property of the OAuth2 Provider service. See "Advanced OpenID Connect"

Specify the method for encrypting the request parameter.

Must match one of the values configured in the Request parameter Encryption Methods supported property of the OAuth2 Provider service. See "Advanced OpenID Connect" .

Default: A128CBC-HS256

Specifies the format of the token introspection response. The possible values for this property are:

Even if the client has configured the response to be JSON-formatted, it can request a signed JWT by adding the "Accept: application/jwt" header to the request. However, when a client that is configured to use either of the JWT-formatted responses requests a JSON response, AM returns an error. For an example, see "/oauth2/introspect".

The JWT response format follows the JWT Response for OAuth Token Introspection Internet Draft.

For related signing and encryption algorithms, see the following properties:

Default: JSON response format

Specifies the algorithm used to sign the token introspection response when it is formatted as a signed JWT.

Must match a value configured in the Token Introspection Response Signing Algorithms Supported property of the OAuth2 Provider service. See "Advanced OpenID Connect" .

AM supports the following signing algorithms:

The signing key used depends on the algorithm chosen. The relevant secret IDs and the default signing key aliases are shown in the table below:

Default: RS256

Specifies the algorithm used to encrypt the token introspection response when it is formatted as a signed then encrypted JWT.

Must match a value configured in the Token Introspection Response Encryption Algorithms Supported property of the OAuth2 Provider service. "Advanced OpenID Connect" .

AM supports the following encryption algorithms:

The algorithms that are not specified as being derived from the client secret use the client's public keys. For more information, see the Public key selector property.

Default: RSA-OAEP-256

Specifies the encryption method used to encrypt the token introspection response when it is formatted as a signed then encrypted JWT.

Must match a value configured in the Token Introspection Response Encryption Methods Supported property of the OAuth2 Provider service. "Advanced OpenID Connect" .

AM supports the following encryption methods:

Default: A128CBC-HS256

Specify one or more allowable URIs to which the client can be redirected after the UMA claims collection process. The URIs must not contain a fragment (#).

If multiple URIs are registered, the client MUST specify the redirection URI to be redirected to following approval.