Prior to configuring an OAuth resource server, you must finish configuring the PingFederate administration.
If you plan to use Mutual TLS, you must make two changes to the PingFederate configuration:
- Enable the use of the secondary HTTPS port in PingFederate by editing the
file and setting the
pf.secondary.https.portvalue to a port value. For more information, see the PingFederate documentation.
- Modify the openid-configuration.template.json file to add
mtls_endpoint_aliasesobject, with content defined by RFC-8705. For more information about this file, see the PingFederate documentation.
To validate the bearer access token, a valid
This configuration is optional and necessary only if you plan to validate PingFederate OAuth access tokens.
To configure an OAuth resource server:
- Click Settings and then go to .
Enter the OAuth Client ID that you defined when creating
the PingAccess OAuth
client in PingFederate.
Confirm that you selected Access Token Validation as the allowed grant type when configuring the OAuth client in PingFederate.
Select a Client Credentials Type, then provide the
information required for the selected credential type.
- 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.
In the Cache Tokens section of the OAuth
Resource Server tab, select whether to retain token details for
- Yes: Selecting Yes reduces communication between PingAccess and PingFederate.
- No: The default value.
If Cache Tokens is enabled, enter the number of seconds
to cache the access token in the Token Time To Live
The default value,
-1, caches the token as long as it's valid.
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
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 that's defined in PingFederate.
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
This option requires you to configure the access token management instances with appropriate Resource URIs. Resource
URImatching is performed on a most-specific match basis. URI URI (Uniform Resource Identifier) Identifies a web resource with a string of characters conforming to a specified format.
- Optional: To disable the use of OAuth 2.0 token introspection, clear the Use Token Introspection Endpoint check box.
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:
- 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.
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, select Require
This check box is cleared by default.
In the DPoP Proof Lifetime (SEC.) field, enter the
duration, in seconds, that a DPoP proof should be considered valid after it's
As a security best practice, keep this value low and consistent with the DPoP implementation of your API client.
- Click Save.