---
title: Configuring OAuth resource servers
description: When receiving OAuth-protected application programming interface (API) calls, PingAccess acts as an OAuth resource server, checking with the PingFederate OAuth authorization server on the validity of the bearer access token it receives from a client.
component: pingaccess
version: 9.0
page_id: pingaccess:pingaccess_user_interface_reference_guide:pa_configuring_oauth_resource_servers
canonical_url: https://docs.pingidentity.com/pingaccess/9.0/pingaccess_user_interface_reference_guide/pa_configuring_oauth_resource_servers.html
revdate: April 30, 2024
section_ids:
  before-you-begin: Before you begin
  about-this-task: About this task
  steps: Steps
  choose-from: Choose from:
  choose-from-2: Choose from:
  choose-from-3: Choose from:
---

# Configuring OAuth resource servers

When receiving OAuth *(tooltip: \<div class="paragraph">
\<p>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.\</p>
\</div>)*-protected application programming interface (API) *(tooltip: \<div class="paragraph">
\<p>A specification of interactions available for building software to access an application or service.\</p>
\</div>)* calls, PingAccess acts as an OAuth resource server, checking with the PingFederate OAuth authorization server on the validity of the bearer access token it receives from a client.

## Before you begin

Before configuring an OAuth resource server, you must finish configuring the [PingFederate administration](pa_configuring_pf_administration.html).

If you plan to use **Mutual TLS**, you must make two changes to the PingFederate configuration:

1. Enable the use of the secondary HTTPS port in PingFederate by editing the `<pf_install>/pingfederate/bin/run.properties` file and setting the `pf.secondary.https.port` value to a port value. Learn more in [Configuring PingFederate properties](https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/pf_config_pf_propert.html).

2. Modify the `openid-configuration.template.json` file to add the `mtls_endpoint_aliases` object, with content defined by [RFC-8705](https://www.rfc-editor.org/rfc/rfc8705#name-metadata-for-mutual-tls-end). Learn more information about this file in the [PingFederate documentation](https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/pf_customiz_openid_provid_config_endpoint_response.html).

## About this task

To validate the bearer access token, a valid OAuth client *(tooltip: \<div class="paragraph">
\<p>The application in an OAuth framework that requests access to resources. If the request is approved by the authorization server, the client is issued an access token for the resources.\</p>
\</div>)* must exist within the PingFederate OAuth authorization server.

|   |                                                                                                             |
| - | ----------------------------------------------------------------------------------------------------------- |
|   | This configuration is optional and necessary only if you plan to validate PingFederate OAuth access tokens. |

To configure an OAuth resource server:

## Steps

1. Click **Settings**, then go to **System > Token Provider > PingFederate > OAuth Resource Server**.

2. Enter the OAuth **Client ID** that you defined when creating the PingAccess OAuth client in PingFederate, as shown in [Configuring OAuth clients](https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/pf_configuring_oauth_clients.html).

   |   |                                                                                                                                    |
   | - | ---------------------------------------------------------------------------------------------------------------------------------- |
   |   | Confirm that you selected **Access Token Validation** as the allowed grant type when configuring the OAuth client in PingFederate. |

3. 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 PingFederate.

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

4. In the **Cache Tokens** section of the **OAuth Resource Server tab**, select whether to retain token details for subsequent requests.

   ### Choose from:

   * **Yes**: Selecting **Yes** reduces communication between PingAccess and PingFederate.

   * **No**: The default value.

5. If **Cache Tokens** is enabled, enter the number of seconds to cache the access token in the **Token Time To Live** field.

   The default value, `-1`, caches the token as long as it's valid.

6. In the **Subject Attribute Name** field, enter the attribute from the OAuth access token that you want to use as the subject for auditing purposes, such as `username`.

   At runtime, the attribute's value is used as the **Subject** field in the audit log entries for API Resources with policies that validate access tokens. The attribute you choose must align with an attribute in the [OAuth access token attribute contract](https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/pf_defining_access_token_attribute_contract.html) that's defined in PingFederate.

7. If multiple access token managers are configured in PingFederate, select the **Send Audience** check box to send the URI that the user requested as the `aud` OAuth parameter to select a specific access token manager.

   |   |                                                                                                                                                                                                                                                                                                                                                                     |
   | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
   |   | This option requires you to configure the access token management instances with appropriate Resource URIs. Resource Uniform Resource Identifier (URI) *(tooltip: \<div class="paragraph">&#xA;\<p>Identifies a web resource with a string of characters conforming to a specified format.\</p>&#xA;\</div>)* matching is performed on a most-specific match basis. |

8. **Optional:** To disable the use of OAuth 2.0 token introspection, clear the **Use Token Introspection Endpoint** check box.

9. In the **DPoP Type** list, select the level of OAuth 2.0 Demonstrating Proof of Possession (DPoP) support that you want to enable for access token validation:

   ### Choose from:

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

     |   |                                                                    |
     | - | ------------------------------------------------------------------ |
     |   | You must use PingFederate 11.3 or later to configure DPoP support. |

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

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

12. Click **Save**.
