--- title: Access token validators description: Access token validators verify the tokens that client applications submit when they request access to a protected resource. component: pingauthorize version: 11.0 page_id: pingauthorize:pingauthorize_server_administration_guide:paz_access_token_validators canonical_url: https://docs.pingidentity.com/pingauthorize/11.0/pingauthorize_server_administration_guide/paz_access_token_validators.html revdate: July 21, 2025 section_ids: about-access-token-validator-processing: About access token validator processing --- # Access token validators Access token validators verify the tokens that client applications submit when they request access to a protected resource *(tooltip: \
\

Information, typically accessed through a web URL, that is protected by an access management system.\

\
)*. Specifically, access token validators translate an access token into a data structure that constitutes part of the input for policy processing. To authenticate to PingAuthorize Server's HTTP services, clients use [OAuth 2 bearer token authentication](https://datatracker.ietf.org/doc/html/rfc6750) to present an access token in the HTTP Authorization request header: ``` "Authorization": "Bearer " ``` | | | | - | -------------------------------------------------------------------------------- | | | PingAuthorize does not support the use of query parameters for token validation. | To process the incoming access tokens, PingAuthorize Server uses access token validators, which determine whether to accept an access token and translate it into a set of properties, called claims. Most access tokens identify a user, also called the token owner, as its subject (SAML) *(tooltip: \
\

A person, computer system, or application. In the SAML context, assertions make statements about subjects.\

\
)*. Access token validators can retrieve the token owner's attributes *(tooltip: \
\

Distinct characteristics that describe a subject. If the subject is a website user, attributes can include a name, group affiliation, email address, and attributes alike.\

\
)* from the datastore *(tooltip: \
\

A database or directory location containing user account records and associated user attributes.\

\
)* using a related component called a token resource lookup method. The user data obtained by a token resource lookup method is sent to the policy decision point (PDP) so that policies can determine whether to authorize the request. Learn more about the types of access tokens PingAuthorize can validate in [Access token validator types](paz_access_token_val_types.html). Learn more about validating a 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\.\

\
)* in policy instead of using a validator in [Conditions](../pingauthorize_policy_administration_guide/paz_conditions.html). ## About access token validator processing Each access token validator possesses an evaluation order index, an integer that determines its processing priority. Lower values are processed before higher values. The following image shows the validation process when using an access token validator with the System for Cross-domain Identity Management (SCIM) *(tooltip: \
\

An application-level, HTTP-based protocol for provisioning and managing user identity information. SCIM supplies a common schema for representing users and groups and provides a REST API.\

\
)* token resource lookup method. ![Diagram of the access token validation flow for a SCIM lookup between , the authorization server, and the directory server](_images/cbi1576100533613.png) 1. If an inbound *(tooltip: \
\

A direction of message flow coming into a service. The type of message depends service's identity access management role.\

\
)* HTTP request *(tooltip: \
\

A client transaction sent over HTTP to the server specifying a request method, such as GET, POST, and DELETE, to execute against a resource or resources on the server.\

\
)* contains an access token, PingAuthorize sends the token to the access token validator with the lowest evaluation order index. 2. The access token validator validates the access token. Validation logic varies by access token validator type, but the validator generally verifies the following information: * A trusted source issued the token. * The token is not expired. If the token is valid, its `active` flag is set to `true`. The flag and other access token claims are added to the `HttpRequest.AccessToken` attribute of the policy request. 3. If the access token contains a subject, the access token validator sets the `user_token` flag to `true` and uses a token resource lookup method to fetch the token owner through SCIM. A token resource lookup defines a SCIM filter that locates the token owner. If the lookup succeeds, the resulting SCIM object is added to the policy request as the `TokenOwner` attribute. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | For deployments that don't use SCIM, token owner attributes can be retrieved from other user store types by writing a token resource lookup method extension with the Server SDK. For more information, see [User profile availability in policies](paz_user_profile_avail_policies.html). | 4. If the access token validator is unable to validate the access token, it passes the token to the access token validator with the next lowest evaluation order index, and the previous two steps are repeated. 5. HTTP request processing continues, and the policy request is sent to the PDP. 6. Policies inspect the `HttpRequest.AccessToken` and `TokenOwner` attributes to make access control decisions. Access tokens issued using 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.\

\
)* 2 client credentials grant type *(tooltip: \
\

The intermediate credentials that represent a resource owner authorization. Grant types are exchanged by the client with the OAuth authorization server in order to obtain an access token.\

\
)* are issued directly to a client and do not contain a subject. An access token validator always sets the `HttpRequest.AccessToken.user_token` flag to `false` for such tokens, which are called application tokens, in contrast to tokens with subjects, which are called user tokens. Because authorization policies often grant a broad level of access for application tokens, you should configure such policies to always check the `HttpRequest.AccessToken.user_token` flag. Access token validators determine whether PingAuthorize Server accepts an access token and uses it to provide key information for access-control decisions, but they are neither the sole nor the primary means of managing access. The responsibility for request authorization falls upon the PDP and its policies. This approach allows an organization to tailor access-control logic to its specific needs.