Token Issuance Authorizers

Token Issuance Authorizers manages the release of scopes through a configurable collection of Token Issuance Authorizer (TIA) plugins that can be assigned to a scope. Various plugins are available that each test for certain conditions to be met, such that the TIA plugin can authorize the issuance of a scope with or without conditions upon issuing a new token.

Token Issuance Process#

When a request is made to issue a token, the scopes to be granted are determined based on what is requested, what is allowed by configuration, and with Token Issuance Authorizers, it is also based on what is authorized by the applicable TIA plugins. The following diagram illustrates the role of TIA plugins in the token issuance process.

Overview of Token Issuance process
Overview of Token Issuance process

The grant types that support Token Issuance Authorization are

  • Authorization Code Flow
  • Client Credentials Flow
  • Refresh Token Flow
  • Resource Owner Password Credentials Flow
  • Device Flow
  • CIBA
  • Token Exchange Flow
  • OAuth Token Exchange Flow
  • Implicit flow
  • JWT Assertion Flow
  • Assisted Token Flow

TIA Plugin Operation#

When a token is being issued, the scopes to be issued together with the context in which the request is made, are provided to the applicable TIA plugins for authorization. This results in an authorization decision for each scope. An authorization decision can be

  • Allow (the scope can be issued)
  • Deny (the scope cannot be issued)
  • Conditional

If a plugin authorizes the issuance of a scope with conditions, then those conditions must be met for the scope to be issued.

The conditions that the TIA plugin can return, are

  • Require User Consent
  • Set Scope Time To Live

The Require User Consent condition allows a TIA plugin to indicate that it is ok to issue the scope, but the user must first give their consent to the release of the scope. This is useful for cases where a scope is considered to be more sensitive and requires an explicit user action to allow it to be released in a token.

Be aware that requiring user consent can only be performed when the user is present, such as during an authorization code flow. If the user is not present, the scope may still be issued when a token is issued based on an existing delegation, but if the user is not present and a token is to be issued based on a new delegation, the scope will not be allowed.

For example, when a client requests an access token by starting the code flow. The user authenticates and the TIA plugins determine that the requested scope messages:read can be issued when user consent is given. The user is prompted for consent and issuance of the scope depends on the user decision.

Continuing the example, the access token expires and the client is using a refresh token to get a new access token. The TIA plugins determine (again) that for the requested scope messages:read, user consent is required. However, since the delegation already exists (implying that conditions for initial token issuance have been met), user consent was implicitly given at the time of the initial token issuance, and the new access token’s scope will include the messages:read scope without actual user-interactive consent.

Another example is when a client requests an access token by starting the JWT Assertion flow. A resulting token will be based on a new delegation. When the TIA plugins indicate that user consent is required for the requested scope messages:read, the scope will not be issued since the user can not be asked for consent to include the scope.

Condition: Set Scope Time To Live#

The Set Scope Time To Live condition allows a TIA plugin to indicate that it is ok to issue the scope, but it must be issued with the specified time to live value. The result is similar to how a lifetime on a scope can be configured , however in the case of it being the result of TIA plugin authorization, the lifetime is determined at the time of token issuance and can be dynamic based on the context of the request.

For example, a TIA plugin could set a shorter lifetime for a scope if the user authentication freshness has passed a certain age.

Configuring Token Issuance Authorizers#

Token Issuance Authorizer plugins are configured in the Token Issuance Authorizers section of the Token Profile. Each plugin has its own configuration options. A configured TIA plugin can be assigned to a scope to create configurable authorization logic to control the release of scopes when issuing tokens.

To create a new TIA plugin, navigate to the Token Authorization section of the Scopes menu and click the +New button.

Token Issuance Authorizers in Admin UI
Token Authorization. (Admin UI version: 11.2)

Assigning Token Issuance Authorizers To Scopes#

To assign a TIA plugin to a scope, navigate to the Scopes section of the Token Profile and click on the scope you want to edit to see Scope details in the right column. A Token Issuance Authorizers section appears where you can select one of the configured TIA plugins that will be applied when that scope is considered to be issued.

Token Issuance Authorizers on Scopes in Admin UI
Token Authorization. (Admin UI version: 11.2)

Provided TIA Plugins#

The following TIA plugins are provided out of the box:

Freshness TIA Plugin

Authentication Freshness

Authorize the issuance of a scope based on the freshness of the user authentication.

ACR TIA Plugin

ACR

Authorize the issuance of a scope based on the ACR of the user authentication.

Grant Type TIA Plugin

Grant Type

Authorize the issuance of a scope based on the grant type used to request the token.

Client Type TIA Plugin

Client Type

Authorize the issuance of a scope based on the type of the client that requests the token.

AuthZen TIA Plugin

AuthZen

Authorize the issuance of scopes by delegating decisions to an external Policy Decision Point using the AuthZen protocol.

Was this helpful?