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".
In the AM console, navigate to Realms > Realm Name > Applications > OAuth 2.0 > Clients.
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.
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*/
, orhttps://[::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
, oren_US_WIN
. If thelocale
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 ofread|
would allow the client to use theread
scope but would not display it to the user when requested.AM reserves special scopes to let clients 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
orscope|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
- 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
orlocale|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
, oren_US_WIN
. If thelocale
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
orlocale|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
, oren_US_WIN
. If thelocale
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.
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. For more information, see "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
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.
By default, the following response types are available:
code
. Specifies that the client application requests an authorization code grant.token
. Specifies that the client application requests an implicit grant type and requests a token from the API.id_token
. Specifies that the client application requests an ID token.code token
. Specifies that the client application requests an access token, access token type, and an authorization code.token id_token
. Specifies that the client application requests an access token, access token type, and an ID token.code id_token
. Specifies that the client application requests an authorization code and an ID token.code token id_token
. Specifies that the client application requests an authorization code, access token, access token type, and an ID token.
- 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 aclient_secret
value.client_secret_post
. Clients authenticate with AM (as an authorization server) by including the client credentials in the request body after receiving aclient_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
, orsub
, 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
, oren_US_WIN
. If thelocale
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 ofname|
would allow the client to use thename
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 individualacr
claim request override these default values.- OpenID Connect JWT Token Lifetime (seconds)
Specify 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
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 JWKs that are 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
orclient_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
, andA256GCM
- AES in Galois Counter Mode (GCM) authenticated encryption mode.A128CBC-HS256
,A192CBC-HS384
, andA256CBC-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:
Secret ID Default Alias Algorithms [a] am.services.oauth2.oidc.signing.ES256 es256test ES256 am.services.oauth2.oidc.signing.ES384 es384test ES384 am.services.oauth2.oidc.signing.ES512 es512test ES512 am.services.oauth2.oidc.signing.RSA rsajwtsigningkey PS256 PS384 PS512 RS256 RS384 RS512 am.services.oauth2.oidc.signing.EDDSA EdDSA with SHA-512 [a] The following applies to confidential clients only:
If you select an HMAC algorithm for signing ID tokens (
HS256
,HS384
, orHS512
), 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. See See "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-HellmanECDH-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. See See "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?
When finished, save your work.
In the AM console, navigate 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.
Adjust the configuration as needed. See "To Create and Configure a Client Profile".
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".
In the AM console, navigate to Realms > Realm Name > Applications > OAuth 2.0. On the Clients tab, select the client ID to which a group is to be assigned.
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.
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.
When finished, save your work.