--- title: Managing client configuration defaults description: On the Client Configuration Defaults tab, specify the default settings that are proprietary to PingFederate for clients created with the OAuth 2.0 Dynamic Client Registration protocol. component: pingfederate version: 13.1 page_id: pingfederate:administrators_reference_guide:help_clientsettingstasklet_oauthdynamicclientregistrationdefaultsstate canonical_url: https://docs.pingidentity.com/pingfederate/13.1/administrators_reference_guide/help_clientsettingstasklet_oauthdynamicclientregistrationdefaultsstate.html llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: June 3, 2024 section_ids: about-this-task: About this task steps: Steps related-links: Related links --- # Managing client configuration defaults On the **Client Configuration Defaults** tab, specify the default settings that are proprietary to PingFederate for clients created with the OAuth 2.0 Dynamic Client Registration protocol. ## About this task Although these settings are shared among all clients created through dynamic client registration, they can be overridden by client registration policies enforced during dynamic client registration. You can also modify the client configuration using the administrative console, administrative API, or OAuth Client Management Service after the client has been created. ## Steps 1. Go to **System > OAuth Settings > Client Settings** and click **Client Configuration Defaults**. 2. (Optional) Modify the default values as needed. The following table describes each field. | Field | Description | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Private Key JWT - Replay Prevention** | This field determines whether PingFederate mandates a unique signed JSON Web Token (JWT) *(tooltip: \
\

An IETF standard container format for a JSON object used for the secure exchange of content, such as identity or entitlement information. You can find the industry standard in \RFC 7519\.\

\
)* from the client for each request when the client is configured to authenticate using the private\_key\_jwt client authentication method, transmit request parameters using signed request objects, or both.This checkbox is cleared by default. The underlying Assertion Replay Prevention Service is cluster-aware. Learn more in Assertion Replay Prevention Service. | | **Require Signed Requests** | Determines whether the client must transmit request parameters in a single, self-contained parameter. The parameter name is `request`. The value of the `request` parameter is a signed JWT whose claims represent the authorization request parameters. The OpenID Connect (OIDC) *(tooltip: \
\

An authentication protocol built on top of OAuth that authenticates users and enables clients (relying parties) of all types to request and receive information about authenticated sessions and users. OIDC is extensible, allowing clients to use optional features such as encryption of identity data, discovery of OpenID Providers (OAuth authorization servers), and session management.\

\
)* (OIDC) specification calls this JWT a request object.This checkbox is cleared by default. | | **Require JWT Secured Authorization Response Mode (JARM)** | When selected, the client must use JARM. The client's authorization requests must include one of the following authorization response mode values:- `jwt`: * Query JWT response in the case of the authorization code grant * Fragment JWT response in the case of the implicit grant - `query.jwt`: * JWT response in the case of the authorization code grant * Failure in the case of the implicit grant unless the response is an encrypted JWT based on the client settings - `fragment.jwt`: Fragment JWT response - `form_post.jwt`: Auto form-post JWT responseJARM is a mechanism to enhance the security of the standard authorization response. It adds support for signing and encryption, sender authentication, and audience restriction. It also offers protection from replay, credential leakage, and mix-up attacks. JARM can be combined with any response type. Learn more in the [JARM specification](https://openid.net/specs/openid-financial-api-jarm.html).This setting works in conjunction with the other **JWT Secured Authorization Response Mode** settings on this page.This checkbox is cleared by default. | | **Require Offline\_Access Scope to Issue Refresh Tokens** | Select to require the authorization server to issue refresh tokens when the `offline_access` scope is requested. | | **Offline\_Access Requires Consent Prompt** | Select to require the prompt parameter value to be set to `consent` when the `offline_access` scope is requested.Available only if **Require Offline\_Access Scope to Issue Refresh Tokens** is selected. | | **Require DPoP JWT Nonce** | Determines whether PingFederate requires a nonce in the Demonstrating Proof-of-Possession (DPoP) JWT for clients created through dynamic client registration.Select one of the following options:- **Use Global Setting** (default) - **Yes** - **No** | | **DPoP JWT Lifetime (Seconds)** | Determines the lifetime of the DPoP JWT for clients created through dynamic client registration.Select one of the following options:- **Use Global Setting** (default) - A custom value in seconds | | **Enforce DPoP JWT Replay Prevention** | Determines whether PingFederate mandates a unique signed DPoP JWT from the client for each request for clients created through dynamic client registration.Select one of the following options:- **Use Global Setting** (default) - **Yes** - **No** The underlying Assertion Replay Prevention Service is cluster-aware. Learn more in Assertion Replay Prevention Service. | | **Default Access Token Manager** | Determines the default Access Token Management (ATM) instance for this client. | | **Restrict to Default Access Token Manager** | If selected, the client can only use the **Default Access Token Manager** even if other ATMs include the client in their access control lists.This checkbox is cleared by default. | | **Persistent Grants Max Lifetime** | Overrides the **Persistent Grant Max Lifetime** value set globally in **System > OAuth Settings > Authorization Server Settings**.Select one of the following options:- **Use Global Setting** (default) - **Grants Do Not Expire** - A custom value in days, hours, or minutes This setting can be overridden per grant-mapping configuration through the use of an extended persistent grant attribute PERSISTENT\_GRANT\_LIFETIME. The PERSISTENT\_GRANT\_LIFETIME attribute is defined in System > OAuth Settings > Authorization Server Settings. When this attribute is active, you can set the lifetime of persistent grants based on the outcome of attribute mapping expressions in individual grant-mapping configurations. For grant-mapping configurations that do not require this fine-grained control, you can configure them to use the default value. | | **Persistent Grants Idle Timeout** | Overrides the Persistent Grant Idle Timeout field value set globally in **System > OAuth Settings > Authorization Server Settings**.Select one of the following options:- **Use Global Setting** (default) - **Grants Do Not Expire** - A custom value in days, hours, or minutesIf you configure an idle timeout value, the idle timeout window slides when a persistent grant updates. When you have an idle timeout value configured without a maximum lifetime, persistent grants remain valid until they expire because of inactivity or until the grant storage revokes or removes them. When you have an idle timeout value configured with a maximum lifetime, persistent grants remain valid until they expire due to inactivity or lifetime expiration or until the grant storage removes them.Learn more in [Transient grants and persistent grants](../introduction_to_pingfederate/pf_transient_grants_persistent_grants.html). | | **Client Authentication Certificate Issuer DN** | Select a trusted CA from the list. You can review CA certificates imported into PingFederate in **Security > Certificate & Key Management > Trusted CAs**. You can select **Trust Any** to trust all the issuers found in the list.The default selection is **None (Client TLS Certificate Authentication Disabled)**, which doesn't allow developers to submit client registrations with a `token_endpoint_auth_method` parameter value of `tls_client_auth`. | | **Refresh Token Rolling Policy** | Overrides the **Roll Refresh Token Values** setting configured globally in **System > OAuth Settings > Authorization Server Settings**.Select one of the following options:- **Use Global Setting** (default) - **Roll** This value doesn't override the **Minimum Interval to Roll Refresh Tokens** value set in the **Authorization Server Settings** page. - **Don't Roll** | | **Refresh Token Rolling Interval** | Overrides the **Minimum Interval to Roll Refresh Tokens** value set in the **Authorization Server Settings** page.Select one of the following options:- **Use Global Setting** (default) - A custom value in hours, minutes, or seconds: * For **Hours**, enter an integer between `0` - `8760` * For **Minutes**, enter an integer between `0` - `525600` * For **Seconds**, enter an integer between `0` - `31536000` | | **Refresh Token Rolling Grace Period (seconds)** | The amount of time in seconds that a rolled refresh token is still valid if the client failed to receive an updated one during a roll.Select one of the following options:- **Use Global Setting** (default) - A custom value in seconds. The maximum is `86400`. For security reasons, we recommend setting the custom value as low as possible. If specified: The currently issued refresh tokens must be refreshed once and converted to the new format. This overrides the Authorization Server Settings default setting. | | **OIDC** | * ID Token Signing Algorithm Select the signing algorithm for the ID tokens from the list. The default algorithm is **RSA using SHA-256**. If the client signs its JWTs using an RSASSA-PSS signing algorithm, PingFederate must be deployed to run in a Java 8 or Java 11 runtime environment or integrated with a hardware security module (HSM) and a static-key configuration for OAuth and OIDC. Learn more about HSM integration and static keys in [Supported hardware security modules](../getting_started_with_pingfederate/pf_supported_hardware_security_modules.html) and [Keys for OAuth and OpenID Connect](help_jwksendpointtasklet_jwksendpointkeysstate.html), respectively. If static keys for OAuth and OpenID Connect are enabled, Elliptic-curve cryptography (EC) algorithms that have not been configured with an active static keys are hidden. Changes made in the static-key configuration might affect runtime transactions and require additional changes here. Learn more in Keys for OAuth and OpenID Connect. While all settings on this page can be overridden by client registration policies enforced during the registration, ID Token Signing Algorithm is the only default setting that can also be overridden by including a different id\_token\_signed\_response\_alg client metadata value in the client registration. For a list of supported signing algorithm, refer tp to the id\_token\_signing\_alg\_values\_supported parameter values returned by the PingFederate OpenID Provider configuration endpoint at /.well-known/openid-configuration. * Policy Select a specific OIDC policy from the list. | | **Device Authorization** | Determines whether to use global device authorization grant settings defined in **System > OAuth Settings > Authorization Server Settings**.The default selection is **Use Global Settings**.You can select **Override** and configure any of the following settings.* User Authorization URL This field controls whether PingFederate should use a different URL when formulating the verification URLs to be included in its device authorization responses. Learn more in [Device authorization endpoint](../developers_reference_guide/pf_device_auth_endpoint.html). For example, if this field is configured with a value of https\://www\.example.org/welcome, PingFederate returns https\://www\.example.org/welcome and https\://www\.example.org/welcome?user\_code=*\* as the verification URIs. After processing the device authorization response, which includes the verification URIs, the device presents one of them to the user. The user is expected to browse to the presented verification URI on a second device. The target web server must redirect the browser to PingFederate at its user authorization endpoint. Learn more in User authorization endpoint. It must also preserve the user\_code parameter value, if provided. For example, if the base URL of your PingFederate server is https\://www\.example.com and this field is configured with a value of https\://www\.example.org/welcome, the target web server must redirect as follows: * https\://www\.example.org/welcome to https\://www\.example.com/as/user\_authz.oauth2 * https\://www\.example.org/welcome?user\_code=*\* to https\://www\.example.com/as/user\_authz.oauth2?user\_code=*\* This field has no default value. * Pending Authorization Timeout (seconds) The lifetime of an activation code (the `user_code` parameter value) in seconds. This field has no default value. * Device Polling Interval (seconds) The amount of time in seconds that the device waits between polling requests to the PingFederate token endpoint.This field has no default value. * Bypass Activation Code Confirmation When PingFederate receives a verification request that includes an activation code (the `user_code` parameter value), it prompts the user to confirm the activation code. This field controls whether PingFederate should skip this confirmation step. Set to `true` if you want PingFederate to skip the confirmation step. This checkbox is cleared by default. | | **Require Proof Key for Code Exchange (PKCE)** | Applicable when the client is configured to support the `authorization_code` grant type.Valid values are `true` or `false`.When enabled, this client must include a one-time string value through the use of the `code_challenge` parameter in its authorization request. For more information, see [Authorization endpoint](../developers_reference_guide/pf_authorization_endpoint.html). It must also submit the corresponding code verifier through the `code_verifier` parameter in its token request when exchanging an authorization code for an access token. Learn more in [OAuth grant type parameters](../developers_reference_guide/pf_oauth_grant_type_param.html).If this parameter isn't provided, the default value of `false` applies.This checkbox is cleared by default. | | **Polling Interval (seconds)** | Specifies the number of seconds that the client must wait between its attempts to check for the authorization results at the token endpoint. When PingFederate receives a token request within this time interval, it returns a `slow_down` error message to the client.Valid values are an integer from `1` - `3600`.The default value is `3`. | | **Policy** | Specifies the CIBA request policy associated with the client.PingFederate uses CIBA request policies to determine various aspects of CIBA authentication request, such as the maximum lifetime of authentication requests, validity of unsigned login hint tokens, and mapping configuration of identity hints.Select an existing CIBA policy.You can also let the selection of **Default** remain to indicate that PingFederate should use the CIBA request policy that has been designated as the default CIBA request policy in **Applications > OAuth > CIBA Request Policies**. | | **Require CIBA Signed Requests** | Determines whether the client must transmit request parameters in a single, self-contained parameter. The parameter name is `request`. The value of the `request` parameter is a signed JWT whose claims represent the authorization request parameters. The [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html) calls this JWT a request object.This checkbox is cleared by default.If client-initiated back channel authentication (CIBA) signed requests are required, the dynamic client registration must include either the JWKS URL or actual JWKS. | | **Token Exchange** | This field determines the token exchange processor policy that PingFederate uses when the OAuth server receives an OAuth token exchange request from the client. If you select **Default**, PingFederate uses the token exchange processor policy that was set as the default on the **Token Exchange Processor Policy Management** tab, under **Applications > Token Exchange > Processor Policies**.Learn more in [OAuth token exchange](pf_oauth_exchange.html). | | **Client Secret Retention Period** | Sets the number of minutes that PingFederate retains a client secret after it is replaced. The retention period lets application teams update the client secret in their apps without disruption.If the value is `0`, PingFederate won't retain replaced secrets.The maximum value is `43800`, which equates to a 1-month retention period.Use one of the following options:* Select **Use Global Setting**, which is configured on the **Authorization Server Settings** page * Override the global setting by entering an integer in the fieldThe default is to use the global setting. Learn more about configuring the global setting in the "Client Secret Retention Period" section in [Configuring authorization server settings](help_authorizationserversettingstasklet_oauthauthorizationserversettingsstate.html). You must select the Retain Client Secret checkbox on the Dynamic Client Registration page for this option to appear. | | **Malicious Actions Count for Lockout** | The maximum number of malicious actions allowed before PingFederate locks out the client.Currently, the only malicious action PingFederate tracks is an attempt to revoke an invalid access token or refresh token.* Use Global Setting Use the default global setting as defined by the `MaxMaliciousActions` parameter in `com.pingidentity.common.security.AccountLockingService.xml`. * Do Not Lockout Disables the lockout function for malicious attempts to revoke an invalid token. * Custom count field Enter an integer to specify the number of malicious actions to allow before PingFederate locks out the client. | | **Tags** | Click the link to open the **Tag Selection** modal.Add tags from the **Available Tags** column by clicking the **Add** icon or dragging a tag into the **Selected Tags** column.Learn more in [Tag Management](pf_tag_management.html). | ## Related links * [Supported client metadata](pf_supp_client_metadata.html) * [OpenID Connect specification, Client Authentication](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) * [OpenID Connect specification, Passing a Request Object by Value](https://openid.net/specs/openid-connect-core-1_0.html) * [OpenID Provider configuration endpoint](../developers_reference_guide/pf_openid_provider_config_endpoint.html)