---
title: Token authorization
description: PingFederate provides an optional configuration known as token authorization to evaluate user attributes as well as other runtime variables, such as authentication context, for authorization purposes.
component: pingfederate
version: 13.1
page_id: pingfederate:introduction_to_pingfederate:pf_token_auth
canonical_url: https://docs.pingidentity.com/pingfederate/13.1/introduction_to_pingfederate/pf_token_auth.html
llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: July 5, 2022
section_ids:
  issuance-criteria: Issuance criteria
  single-and-multivalued-conditions: Single and multivalued conditions
  related-links: Related links
---

# Token authorization

PingFederate provides an optional configuration known as token authorization to evaluate user attributes as well as other runtime variables, such as authentication context, for authorization purposes.

Token authorization provides a way for administrators to extend access policy directly to many areas, such as browser single sign-on (SSO), security token service (STS), and OAuth events, by conditionally allowing or disallowing the issuance of relevant security tokens such as SAML assertions, STS tokens, OAuth access tokens, or session cookies. The option is also available for extending authorization policy to attribute-query responses, identity provider (IdP) adapter contracts, and authentication policy contracts.

Administrators can configure token authorization using Issuance Criteria windows immediately following the configuration of attribute mapping at all applicable points in the administrative console. See [Defining issuance criteria for IdP Browser SSO](../administrators_reference_guide/pf_defining_issuance_criteria_idp_browser_sso.html) as an example.

## Issuance criteria

The token-authorization configuration consists of rules that evaluate attribute values against selected conditions. Depending on the type of configuration that contains the token-authorization setup, choose from among several sources for the attributes. The sources always consist of all of those available for attribute mapping, including configured data stores and runtime information related to the context of an event. In addition, the sources use values of mapped attributes to provide access to any plain-text mappings or the runtime results of any attribute mapping expressions.

|   |                                                                                                                                                                                                                                                                                                                          |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|   | When more than one condition is configured, all are evaluated and all the conditions must be met at runtime (evaluated as true) for authorization to succeed and processing to continue. In cases where you might need "or" conditions or layered evaluations, you can create one or more attribute mapping expressions. |

|   |                                                                                                                                                                                                                                                                                             |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | When authorization fails and a transaction halts, the system passes back a configurable `Error Result` code, potentially to an application layer or as a variable on a PingFederate user-facing template. How this code is interpreted depends on the use case and application integration. |

## Single and multivalued conditions

Each token-authorization configuration provides a choice of conditions for evaluating attribute values:

* equal to

* equal to (case insensitive)

* equal to DN

* not equal to

* not equal to (case insensitive)

* not equal to DN

* multi-value contains

* multi-value contains (case insensitive)

* multi-value contains DN

* multi-value does not contain

* multi-value does not contain (case insensitive)

* multi-value does not contain DN

|   |                                                                                                                                                                                                                                                                                                                                                          |
| - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | The first six conditions are intended for single-value attributes. Use one of the **multi-value …​** conditions when you want PingFederate to validate whether one of the attribute values matches or does not match the specified value. Using a single-value condition when an attribute has multiple values causes the criteria to fail consistently. |

## Related links

* [Attribute mapping expressions](../administrators_reference_guide/pf_attribute_mapping_expressions.html)