--- title: Configuring OAuth authorization servers description: Configure, modify, and edit the OAuth authorization servers in PingAccess. component: pingaccess version: 9.0 page_id: pingaccess:pingaccess_user_interface_reference_guide:pa_configuring_oauth_authz_servers canonical_url: https://docs.pingidentity.com/pingaccess/9.0/pingaccess_user_interface_reference_guide/pa_configuring_oauth_authz_servers.html revdate: December 4, 2023 section_ids: before-you-begin: Before you begin steps: Steps choose-from: Choose from: --- # Configuring OAuth authorization servers Configure, modify, and edit the OAuth *(tooltip: \
\

A standard framework that enables an application (OAuth client) to obtain access tokens from an OAuth authorization server for the purpose of retrieving protected resources on a resource server.\

\
)* authorization servers in PingAccess. ## Before you begin If you plan to use **Mutual TLS**, modify the token provider to provide the `mtls_endpoint_aliases` object, with content defined by [RFC-8705](https://www.rfc-editor.org/rfc/rfc8705#name-metadata-for-mutual-tls-end), on 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.\

\
)* well-known configuration endpoint *(tooltip: \
\

One end in a communication channel, typically a URI.\

\
)*. ## Steps 1. Click **Settings**, then go to **System > Token Provider > Common > OAuth Authorization Server**. 2. **Optional:** In the **Description** field, enter a description for the authorization server. 3. In the **Targets** field, enter one or more `hostname:port` pairs for the OAuth *(tooltip: \
\

A standard framework that enables an application (OAuth client) to obtain access tokens from an OAuth authorization server for the purpose of retrieving protected resources on a resource server.\

\
)* authorization server. 1. **Optional:** Click **[icon: plus, set=fa]Add Target** to add additional targets. 4. In the **Introspection Endpoint** field, specify the OAuth endpoint through which the token introspection operation is accomplished. | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | If you've configured a remote token access validator on your PingAccess application and try to remove the **Introspection Endpoint** or save without configuring it on the **OAuth Authorization Server** tab, you get the following error message:``` Introspection endpoint is required as there are applications that use remote token validation. ```Remove the remote access token validator before filling out your configuration on the **OAuth Authorization Server** tab. | 5. In the **Token Endpoint** field, enter the OAuth 2.0 Authorization Server's token endpoint. 6. To record requests to the OAuth authorization server to the audit store, select the **Audit** check box. 7. If the OAuth authorization server is expecting HTTPS connections, select the **Secure** option. 8. In the **Trusted Certificate Group** list, select the group of certificates to use when authenticating to the OAuth authorization server. PingAccess requires that the certificate in use by the OAuth authorization server anchors to a certificate in the associated trusted certificate group. 9. In the **Client ID** field, enter the unique identifier assigned when you created the PingAccess OAuth client within your OAuth authorization server. 10. Select a **Client Credentials Type**, then provide the information required for the selected credential type. ### Choose from: * **Secret**: Enter the **Client Secret** assigned when you created the PingAccess OAuth client in the token provider. * **Mutual TLS**: Select a configured **Key Pair** to use for mutual TLS client authentication. * **Private Key JWT**: Select this option to use Private Key JSON web token (JWT). No additional information is required. 11. **Optional:** To retain token details for subsequent requests, select the **Cache Tokens** option. This option reduces communication between PingAccess and the OAuth authorization server. 12. **Optional:** To enter the number of seconds to cache the access token, select the **Token Time To Live** check box. A value of -1 means that there is no limit. This value should be less than the OAuth authorization server token lifetime. 13. In the **Subject Attribute Name** field, enter the attribute that you want to use from the OAuth access token as the subject for auditing purposes. At runtime, the attribute's value is used as the subject field in audit log entries for application programming interface (API) *(tooltip: \
\

A specification of interactions available for building software to access an application or service.\

\
)* resources with policies that validate access tokens. 14. To send the URI the user requested as the `aud` OAuth parameter for PingAccess to the OAuth 2.0 authorization server, select the **Send Audience** check box. 15. To configure the connection to use a configured proxy, click **Show Advanced Settings** and select **Use Proxy**. For more information about creating proxies, see [Adding proxies](pa_adding_proxies.html). 16. To configure OAuth 2.0 Demonstrating Proof of Possession (DPoP) settings, click **Show Advanced Settings**: 1. In the **DPoP Type** list, select the level of DPoP support that you want to enable for access token validation: * **Off** (default): PingAccess doesn't accept DPoP-bound access tokens, only bearer tokens. * **Enabled**: PingAccess accepts both bearer tokens and DPoP-bound access tokens. * **Required**: PingAccess doesn't accept bearer tokens, only DPoP-bound access tokens. 2. To require each DPoP proof to contain a nonce value during validation that was provided by PingAccess when the access token was created, per [RFC 9449 section 9](https://www.rfc-editor.org/rfc/inline-errata/rfc9449.html#:~:text=Next%20Nonce%20Value-,9.%20%20Resource%20Server%2DProvided%20Nonce,-Resource%20servers%20can), select **Require Nonce**. This check box is cleared by default. 3. In the **DPoP Proof Lifetime (SEC.)** field, enter the duration, in seconds, that a DPoP proof should be considered valid after it's issued. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------- | | | As a security best practice, keep this value low and consistent with the DPoP implementation of your API client. The default value is 120 seconds. | 17. Click **Save**. | | | | - | -------------------------------------------------------------------------------------------- | | | If the node isn't configured with a proxy, requests are made directly to the token provider. |