Metadata field Metadata description
client_name A descriptive name for the client instance. This name appears when the user is prompted for authorization.
token_endpoint_auth_method The client authentication method.

Allowed values:

  • none
  • client_secret_basic
  • client_secret_post
  • tls_client_auth

    For more information, see Mutual TLS Profiles for OAuth clients (tools.ietf.org/html/draft-ietf-oauth-mtls-01).

  • private_key_jwt

    For more information, see Client Authentication in the OpenID Connect specification (openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication).
tls_client_auth_subject_dn The subject DN of the client certificate.

Required if tls_client_auth is the value of the token_endpoint_auth_method parameter
token_endpoint_auth_signing_alg The signing algorithm that the client must use to sign the JWTs for client authentication.

Applicable only when the token_endpoint_auth_method parameter is provided with a value of private_key_jwt.

Allowed values:
  • RS256 - RSA using SHA-256
  • RS384 - RSA using SHA-384
  • RS512 - RSA using SHA-512
  • ES256 - ECDSA using P256 Curve and SHA-256
  • ES384 - ECDSA using P384 Curve and SHA-384
  • ES512 - ECDSA using P521 Curve and SHA-512
  • PS256 - RSASSA-PSS using SHA-256
  • PS384 - RSASSA-PSS using SHA-384
  • PS512 - RSASSA-PSS using SHA-512
    Note:

    RSASSA-PSS signing algorithms require either a Java 11 runtime environment or an integration with a hardware security module (HSM) and a static-key configuration for OAuth and OpenID Connect. (For more information on HSM integration and static keys, see Supported hardware security modules and Managing keys for OAuth and OpenID Connect, respectively.)

If this parameter is not provided, the client can use any of the supported signing algorithms.

request_object_signing_alg The signing algorithm that the client must use to sign its request objects for transmission of request parameters.

Applicable only when the client may send its authorization requests using request objects.

Allowed values:
  • RS256 - RSA using SHA-256
  • RS384 - RSA using SHA-384
  • RS512 - RSA using SHA-512
  • ES256 - ECDSA using P256 Curve and SHA-256
  • ES384 - ECDSA using P384 Curve and SHA-384
  • ES512 - ECDSA using P521 Curve and SHA-512
  • PS256 - RSASSA-PSS using SHA-256
  • PS384 - RSASSA-PSS using SHA-384
  • PS512 - RSASSA-PSS using SHA-512
    Note:

    RSASSA-PSS signing algorithms require either a Java 11 runtime environment or an integration with a hardware security module (HSM) and a static-key configuration for OAuth and OpenID Connect. (For more information on HSM integration and static keys, see Supported hardware security modules and Managing keys for OAuth and OpenID Connect, respectively.)

When this parameter is not provided, the client can use any of the supported signing algorithms.

For more information about request object, please refer to the OpenID Connect specification (openid.net/specs/openid-connect-core-1_0.html#RequestObject).

jwks_uri, and

jwks

 The URL of the JSON Web Key Set (JWKS) or the actual JWKS from the client.

Only one of them is required if the client is configured to use the private_key_jwt client authentication method, to transmit request parameters in signed request objects, or to transmit CIBA request parameter in signed request objects (or to do any of them) so that PingFederate can verify the authenticity of the JWTs.

In addition, either may also be defined even if the client is not configured to use JWTs for authentication or transmission of request parameters. This flexibility allows the client to transmit request parameters in signed request objects for some requests and without the use of signed request objects for some other transactions. (For runtime processing, see Authorization endpoint.)

If the client signs its JWTs using an RSASSA-PSS signing algorithm, PingFederate must be deployed to run in a Java 11 runtime environment or integrated with a hardware security module (HSM) to process the digital signatures. (For more information on HSM integration, see Supported hardware security modules.)

Finally, if the client is configured to encrypt ID tokens using an asymmetric encryption algorithm (see the ID Token Key Management Encryption Algorithm setting), either the JWKS URL or the actual JWKS must be provided.

redirect_uris An array of one or more redirection URIs to which the OAuth AS may redirect the resource owner's user agent after authorization is obtained. At least one redirection URI is required by the authorization code and implicit grant types.
logo_uri The location of the logo used on user-facing OAuth grant authorization and revocation pages. (For best results with the installed HTML templates, the recommended size is 72 x 72 pixels.)
scope A space-separated list of one or more scopes, for which a client can request.
grant_types An array of one or more grant types, for which a client can request.
Allowed values:
  • authorization_code
  • implicit
  • refresh_token
  • client_credentials
  • urn:ietf:params:oauth:grant-type:device_code
  • urn:openid:params:grant-type:ciba
  • password
  • extension (JWT Bearer Token or SAML 2.0 Bearer Assertion)
  • urn:pingidentity.com:oauth2:grant_type:validate_ bearer

(For more information about each grant type, see Grant types.)
response_types An array of one or more response types, for which a client can request.
Allowed values:
  • code
  • code id_token
  • code id_token token
  • code token
  • id_token
  • id_token token
  • token

For more information about these response types, see Definitions of Multiple-Valued Response Type Combinations (openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations).

If one or more response types are specified, the resulting client is only allowed to send one of the specified response types at runtime. Requests from this client with other response types will be rejected.

Additionally, it is worth noting that the response types and grant types parameters must be provided in tandem because certain response types require one or more grant types, and vice versa. The following table provides a summary of their relationship.

response type grant types
code authorization_code
code id_token authorization_code and implicit
code id_token token authorization_code and implicit
code token authorization_code and implicit
id_token implicit
id_token token implicit
token implicit
id_token_signed_response_alg The JSON Web Signature (JWS) algorithm required for the OpenID Connect ID tokens.
Allowed values:
  • none - No signing algorithm
  • HS256 - HMAC using SHA-256
  • HS384 - HMAC using SHA-384
  • HS512 - HMAC using SHA-512
  • ES256 - ECDSA using P256 Curve and SHA-256
  • ES384 - ECDSA using P384 Curve and SHA-384
  • ES512 - ECDSA using P521 Curve and SHA-512
  • RS256 - RSA using SHA-256
  • RS384 - RSA using SHA-384
  • RS512 - RSA using SHA-512
  • PS256 - RSASSA-PSS using SHA-256
  • PS384 - RSASSA-PSS using SHA-384
  • PS512 - RSASSA-PSS using SHA-512
    Note:

    RSASSA-PSS signing algorithms require either a Java 11 runtime environment or an integration with a hardware security module (HSM) and a static-key configuration for OAuth and OpenID Connect. (For more information on HSM integration and static keys, see Supported hardware security modules and Managing keys for OAuth and OpenID Connect, respectively.)

Important:

If static keys for OAuth and OpenID Connect are enabled, use either an RSA algorithm or an EC algorithm that has been configured with an active static key.
id_token_encrypted_response_alg The algorithm used to encrypt or otherwise determine the value of the content encryption key.
Allowed values:
  • dir - Direct Encryption with symmetric key
  • A128KW - AES-128 Key Wrap
  • A192KW - AES-192 Key Wrap
  • A256KW - AES-256 Key Wrap
  • A128GCMKW - AES-GCM-128 key encryption
  • A192GCMKW - AES-GCM-192 key encryption
  • A256GCMKW - AES-GCM-256 key encryption
  • ECDH-ES - ECDH-ES
  • ECDH-ES+A128KW - ECDH-ES with AES-128 Key Wrap
  • ECDH-ES+A192KW - ECDH-ES with AES-192 Key Wrap
  • ECDH-ES+A256KW - ECDH-ES with AES-256 Key Wrap
  • RSA-OAEP - RSAES-OAEP
id_token_encrypted_response_enc The content encryption algorithm used to perform authenticated encryption on the plain text payload of the token.

Required if an algorithm is provided through the id_token_encrypted_response_alg parameter.

Allowed values:
  • A128CBC-HS256 - Composite AES-CBC-128 HMAC-SHA-256
  • A192CBC-HS384 - Composite AES-CBC-192 HMAC-SHA-384
  • A256CBC-HS512 - Composite AES-CBC-256 HMAC-SHA-512
  • AES-GCM-128 - A128GCM
  • AES-GCM-192 - A192GCM
  • AES-GCM-256 - A256GCM
backchannel_token_delivery_mode The token delivery method supported by the client. PingFederate supports poll and ping.

Set to poll if the client can check for the authorization results periodically at the token endpoint.

Set to ping if the client prefers to wait for a ping callback message from PingFederate as a signal that the authorization result is ready for pickup.

If this parameter is not provided and the CIBA grant type is enabled, the poll method is assumed.

backchannel_client_notification_endpoint The client's notification endpoint, to which PingFederate sends its ping call back messages.

Required only if ping is the configured token delivery method.

backchannel_authentication_request_signing_alg The signing algorithm that the client must use to sign its request objects for transmission of request parameters.
Allowed values:
  • RS256 - RSA using SHA-256
  • RS384 - RSA using SHA-384
  • RS512 - RSA using SHA-512
  • ES256 - ECDSA using P256 Curve and SHA-256
  • ES384 - ECDSA using P384 Curve and SHA-384
  • ES512 - ECDSA using P521 Curve and SHA-512
  • PS256 - RSASSA-PSS using SHA-256
  • PS384 - RSASSA-PSS using SHA-384
  • PS512 - RSASSA-PSS using SHA-512
    Note:

    RSASSA-PSS signing algorithms require either a Java 11 runtime environment or an integration with a hardware security module (HSM) and a static-key configuration for OAuth and OpenID Connect. (For more information on HSM integration and static keys, see Supported hardware security modules and Managing keys for OAuth and OpenID Connect, respectively.)

If this parameter is not provided and the CIBA grant type is enabled, the client can use any of the allowed signing algorithms.

backchannel_user_code_parameter

Indicates whether the client supports user code.

The purpose of this code is to authorize the transmission of an authentication request to the user's authentication device.

A valid value is either true or false.

If this parameter is not provided and the CIBA grant type is enabled, user code support is not enabled.

Note that when user code support is enabled, the associated CIBA request policy must also be user code-enabled.

sector_identifier_uri A URL using the HTTPS scheme that references a JSON file containing an array of redirect_uri values (see https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation).
subject_type The type of subject used by the sector identifier; for example, public or pairwise.