Access token validator types - PingAuthorize - 9.1

This step allows the authorization server to determine whether a token is valid.

Because this step requires an outgoing HTTP request to the authorization server, the PingFederate access token validator might perform slower than other access token validator types. The validation result is guaranteed to be current, which is an important consideration if the authorization server permits the revocation of access tokens.

Before attempting to use a PingFederate access token validator, create a client that represents the access token validator in the PingFederate configuration. This client must use the Access Token Validation grant type.

The JWT access token validator inspects the JWT token without presenting it to an authorization server for validation. Because the JWT access token validator doesn't make a token introspection request for every access token that it processes, it performs faster than the PingFederate access token validator. The access token is self-validated however, so the JWT access token validator cannot determine whether the token has been revoked.

Supported JWS/JWE features

For signed tokens, the JWT access token validator supports the following JWT web algorithm (JWA) types:

• RS256
• RS384
• RS512
• ES256
• ES384
• ES512

For encrypted tokens, the JWT access token validator supports the following key-encryption algorithms:

• RSA-OAEP
• ECDH-ES
• ECDH-ES+A128KW
• ECDH-ES+A192KW
• ECDH-ES+A256KW

For encrypted tokens, the JWT access token validator supports the following content-encryption algorithms:

• A128CBC-HS256
• A192CBC-HS384
• A256CBC-HS512

The JWT access token validator configuration defines three allow lists for the JWS/JWE signing and encryption algorithms that it will accept. You should customize these allow lists to reflect only the signing and encryption algorithms used by your access token issuer and no others. Doing so minimizes the access token validator's security threat surface.

Configure these allow lists using the following configuration properties.

A mock access token validator is a special access token validator type used for development or testing purposes; it accepts arbitrary tokens without validating whether a trusted source issued them. This approach allows a developer or tester to make bearer token-authenticated requests without first setting up an authorization server.

Mock access tokens are formatted as plain-text JSON objects using standard JSON web token (JWT) claims.

Always provide the Boolean active claim when creating a mock token. If this value is true, the token is accepted. If this value is false, the token is rejected.

If the sub claim is provided, a token owner lookup populates the TokenOwner policy request attribute, as with the other access token validator types.

The following example cURL command provides a mock access token in an HTTP request:

curl -k -X GET https://localhost:8443/scim/v2/Me -H 'Authorization: Bearer {"active": true, "sub":"user.3", "scope":"email profile", "client":"client1"}'

To create custom access token validators, use the Server SDK.