Client Registration

You can register OAuth 2.0/OpenID Connect clients with the AM OAuth 2.0 authorization service by creating and configuring a client profile. When creating a client profile, you must provide at least the client identifier and client secret.

Alternatively, you can register a client dynamically. AM supports open registration, registration with an access token, and registration including a secure software statement issued by a software publisher.

You can also create an OAuth 2.0 client profile group. OAuth 2.0 clients within a group can specify one or more properties that inherit their values from the group, allowing configuration of multiple OAuth 2.0 clients simultaneously. For more information, see "To Configure a Client Profile Group".

To Create and Configure a Client Profile
  1. In the AM console, go to Realms > Realm Name > Applications > OAuth 2.0 > Clients.

  2. Click Add Client, and then provide the Client ID, Client secret, Redirection URIs, Scope(s), and Default Scope(s).

    Finally, click Create to create the profile.

  3. Adjust the configuration as needed using the inline help for hints and the following documentation:

    Group

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

    Status

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

    Client secret

    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.

    Client type

    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.

    Allow wildcard ports in redirection URIs

    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.

    Redirection URIs

    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.

    Scope(s)

    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.

    Default Scope(s)

    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.

    Client Name

    Specify a human-readable name for the client.

    Authorization Code Lifetime (seconds)

    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

    Refresh Token Lifetime (seconds)

    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

    Access Token Lifetime (seconds)

    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

    Token Exchange Auth Level

    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

    Display name

    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.

    Display description

    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.

    JavaScript Origins

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

    Note

    This property does not support using a non-standard header. To use a custom header, you must create a new CORS configuration.

    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.

    Important

    Ensure that customers whitelist all headers for CORS and OAuth 2.0 client integration with AM.

    For more information, refer to "Configuring CORS Support".

    Request uris

    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.

    Grant Types

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

    • Authorization Code

    • Back Channel Request

    • Implicit

    • Resource Owner Password Credentials

    • Client Credentials

    • Refresh Token

    • UMA

    • Device Code

    • SAML2

    • Token Exchange

    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

    Response Types

    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:

    • code. Specifies that the client requests an authorization code during the OAuth 2.0 "Authorization Code Grant" or the OpenID Connect "Authorization Code Grant" flows.

      This response type also applies to the Authorization Code grant with PKCE flows.

    • token. Specifies that the client requests an access token during the "Implicit Grant" flow.

    • id_token. Specifies that the client requests an ID token during the OpenID Connect "Implicit Grant" flow.

    • code token. Specifies that the client requests an access token and an authorization code during the OpenID Connect "Hybrid Grant" flow.

    • code id_token. Specifies that the client requests an authorization code and an ID token during the OpenID Connect "Hybrid Grant" flow.

    • code token id_token. Specifies that the client application requests an authorization code, an access token, and an ID token, during the OpenID Connect "Hybrid Grant" flow.

    • token id_token. Specifies that the client requests an access token and an ID token during the OpenID Connect "Implicit Grant" flow.

    Contacts

    Specify the email addresses of users who administer the client.

    Token Endpoint Authentication Method

    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.

    • client_secret_basic. Clients authenticate with AM (as an authorization server) using the HTTP Basic authentication scheme after receiving a client_secret value.

    • client_secret_post. Clients authenticate with AM (as an authorization server) by including the client credentials in the request body after receiving a client_secret value.

    • private_key_jwt. Clients sign a JSON web token (JWT) with a registered public key.

    • tls_client_auth. Clients use a CA-signed certificate for mutual TLS authentication.

    • self_signed_tls_client_auth. Clients use a self-signed certificate for mutual TLS authentication.

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

    Sector Identifier URI

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

    Subject Type

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

    • public. Provides the same sub (subject) value to all clients.

    • pairwise. Provides a different sub (subject) value to each client.

    Access Token

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

    Client URI

    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

    Logo URI

    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

    Privacy Policy URI

    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

    Implied Consent

    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.

    OAuth 2.0 Mix-Up Mitigation enabled

    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.

    Claim(s)

    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.

    Post Logout Redirect URIs

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

    Client Session URI

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

    Default Max Age

    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

    Default Max Age Enabled

    Enable the default max age feature.

    Default ACR values

    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.

    OpenID Connect JWT Token Lifetime (seconds)

    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

    Backchannel Logout URL

    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".

    Backchannel Logout Session Required

    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".

    AM returns an error if the administrator tries to save a client profile configuration containing an unsupported signing or encryption algorithm on a client.

    For example, upon saving the configuration, AM will return an error if there is a typo on an algorithm, or a symmetric signing or encryption algorithm is configured on a public client: these algorithms are derived from the client's secret, which public clients do not have.

    Clients registering dynamically must also send supported algorithms as part of their configuration, or AM will reject the registration request.

    Different features support different algorithms. Refer to the documentation or the UI for more information.

    Json Web Key URI

    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.

    JWKs URI content cache timeout in ms

    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

    JWKs URI content cache miss cache time

    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

    Token Endpoint Authentication Signing Algorithm

    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

    Json Web Key

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

    ID Token Signing Algorithm

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

    Enable ID Token Encryption

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

    ID Token Encryption Algorithm

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

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

    ID Token Encryption Method

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

    Default value: A128CBC-HS256.

    Client ID Token Public Encryption Key

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

    Client JWT Bearer Public Key Certificate

    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".

    mTLS Self-Signed Certificate

    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"

    mTLS Subject DN

    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".

    Use Certificate-Bound Access Tokens

    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"

    Public key selector

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

    • JWKs_URI

      Configure a URI that exposes the client public keys in the Json Web Key URI field, and ensure the following related properties have sensible values for your environment:

      • JWKs URI content cache timeout in ms

      • JWKs URI content cache miss cache time

    • JWKs

      Enter a JWK Set containing one or more keys in the Json Web Key field. For example:

      {
          "keys": [
              {
                  "kty": "RSA",
                  "n": ...
              },
              ...
          ]
      }
    • X509

      Enter a key object or a single certificate in one of the following fields, depending on the feature you are configuring:

      • (ID token encryption) Client ID Token Public Encryption Key. Requires an RSA public key object in X.509 PEM format. For example:

        -----BEGIN PUBLIC KEY-----
        ......
        -----END PUBLIC KEY-----
      • (JWT client authentication) Client JWT Bearer Public Key. Requires a X.509 certificate in PEM format. For example:

        -----BEGIN CERTIFICATE-----
        .....
        -----END CERTIFICATE-----
      • (mTLS client authentication) mTLS Self-Signed Certificate. Requires a X.509 certificate in PEM format. For example:

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

    Default: JWKs_URI

    User info response format.

    Specify the output format from the UserInfo endpoint.

    The supported output formats are as follows:

    • User info JSON response format.

    • User info encrypted JWT response format.

    • User info signed JWT response format.

    • User info signed then encrypted response format.

    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.

    User info signed response algorithm

    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.

    User info encrypted response algorithm

    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.

    User info encrypted response encryption algorithm

    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:

    • A128GCM, A192GCM, and A256GCM - AES in Galois Counter Mode (GCM) authenticated encryption mode.

    • A128CBC-HS256, A192CBC-HS384, and A256CBC-HS512 - AES encryption in CBC mode, with HMAC-SHA-2 for integrity.

    Default: A128CBC-HS256

    Request parameter signing algorithm

    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" .

    Request parameter encryption algorithm

    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"

    Request parameter encryption method

    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

    Token introspection response format

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

    • JSON response format

    • Signed JWT response format

    • Signed then encrypted JWT response format

    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:

    • Token introspection response signing algorithm

    • Token introspection response encryption algorithm

    • Token introspection response encryption method

    Default: JSON response format

    Token introspection response signing algorithm

    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:

    • HS256 - HMAC with SHA-256.

    • HS384 - HMAC with SHA-384.

    • HS512 - HMAC with SHA-512.

    • ES256 - ECDSA with SHA-256 and NIST standard P-256 elliptic curve.

    • ES384 - ECDSA with SHA-384 and NIST standard P-384 elliptic curve.

    • ES512 - ECDSA with SHA-512 and NIST standard P-521 elliptic curve.

    • RS256 - RSASSA-PKCS-v1_5 using SHA-256.

    • RS384 - RSASSA-PKCS-v1_5 using SHA-384.

    • RS512 - RSASSA-PKCS-v1_5 using SHA-512.

    • EdDSA - EdDSA with SHA-512.

    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:

    The following table shows the secret ID mapping used to sign OpenID Connect ID tokens and backchannel logout tokens:

    Secret IDDefault AliasAlgorithms [a]
    am.services.oauth2.oidc.signing.ES256es256testES256
    am.services.oauth2.oidc.signing.ES384es384testES384
    am.services.oauth2.oidc.signing.ES512es512testES512
    am.services.oauth2.oidc.signing.RSArsajwtsigningkey
    PS256
    PS384
    PS512
    RS256
    RS384
    RS512
    am.services.oauth2.oidc.signing.EDDSAEdDSA with SHA-512

    [a] The following applies to confidential clients only:

    If you select an HMAC algorithm for signing ID tokens (HS256, HS384, or HS512), the Client Secret property value in the OAuth 2.0 Client is used as the HMAC secret instead of an entry from the secret stores.

    Since the HMAC secret is shared between AM and the client, a malicious user compromising the client could potentially create tokens that AM would trust. Therefore, to protect against misuse, AM also signs the token using a non-shared signing key configured in the am.services.oauth2.jwt.authenticity.signing secret ID.

    Default: RS256

    Token introspection response encryption algorithm

    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:

    • A128KW - AES Key Wrapping with 128-bit key derived from the client secret.

    • A192KW - AES Key Wrapping with 192-bit key derived from the client secret.

    • A256KW - AES Key Wrapping with 256-bit key derived from the client secret.

    • RSA-OAEP - RSA with Optimal Asymmetric Encryption Padding (OAEP) with SHA-1 and MGF-1.

    • RSA-OAEP-256 - RSA with OAEP with SHA-256 and MGF-1.

    • RSA1_5 - RSA with PKCS#1 v1.5 padding.

    • dir - Direct encryption with AES using the hashed client secret.

    • ECDH-ES - Elliptic Curve Diffie-Hellman

    • ECDH-ES+A128KW - Elliptic Curve Diffie-Hellman + AES Key Wrapping with 128-bit key.

    • ECDH-ES+A192KW - Elliptic Curve Diffie-Hellman + AES Key Wrapping with 192-bit key.

    • ECDH-ES+A256KW - Elliptic Curve Diffie-Hellman + AES Key Wrapping with 256-bit key.

    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

    Token introspection response encryption method

    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:

    • A128GCM, A192GCM, and A256GCM - AES in Galois Counter Mode (GCM) authenticated encryption mode.

    • A128CBC-HS256, A192CBC-HS384, and A256CBC-HS512 - AES encryption in CBC mode, with HMAC-SHA-2 for integrity.

    Default: A128CBC-HS256

    Client Redirection URIs

    Note

    This property is for future use, and not currently active.

    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.

    Some of the configuration of the clients will depend on the configuration of the authorization server, and the type of client you are registering.

    Some basic points you must decide on are:

    • Is the client public or confidential?

    • What is its redirection URI?

    • Which scopes does it need?

    • What's the name this client will show as in the UI pages?

    • Which grant types the client can use to request tokens?

    • Which tokens can this client request?

    • In the case of an OpenID Connect client:

      • If the client is confidential, which authentication method will it use?

      • Which claims does the client need?

  4. When finished, save your work.

To Configure a Client Profile Group
  1. In the AM console, go to Realms > Realm Name > Applications > OAuth 2.0.

    • To create a new OAuth 2.0 client profile group:

      On the Groups tab, select Add Group, and then provide the Group ID. Finally, select Create.

    • To configure a OAuth 2.0 client profile group:

      On the Groups tab, select the group to configure.

  2. Adjust the configuration as needed. See "To Create and Configure a Client Profile".

  3. When finished, save your work.

    If the group is assigned to one or more OAuth 2.0 client profiles, changes to inherited properties in the group are also applied to the client profile.

    To assign a group to an OAuth 2.0 client profile, see "To Assign a Group to a Client Profile and Inherit Properties".

To Assign a Group to a Client Profile and Inherit Properties
  1. In the AM console, go to Realms > Realm Name > Applications > OAuth 2.0. On the Clients tab, select the client ID to which a group is to be assigned.

  2. On the Core tab, select the group to assign to the client from the Group drop-down.

    Warning

    Adding or changing an assigned group will refresh the settings page. Unsaved property values will be lost.

    The inheritance (padlock) icons appear next to properties that support inheriting their value from the assigned group. Not all properties can inherit their value, such as, the Client secret property.

    OAuth 2.0 Client Profile Group Inheritance
    OAuth 2.0 Client Profile Group Inheritance

  3. Inherit a property value from the group by selecting the inheritance button (the open padlock icon) next to the property.

    The value will be inherited from the group and the field will be locked.

    Note

    If you change the group, properties with inheritance enabled will inherit the value from the new group.

    If you remove the group, inherited property values are written to the OAuth 2.0 client profile, and become editable.

  4. When finished, save your work.

Read a different version of :