This feature allows resource servers, for example, to exchange access tokens for other security tokens that are required to call additional APIs, much like what a microservices architecture requires. PingFederate’s native support of subject tokens and actor tokens opens new use cases around delegation and impersonation, which ultimately enriches the end-user experience as resources flow through seamlessly among the backend services used by the user-facing applications.

An OAuth token exchange transaction begins when an OAuth client sends the authorization server a request with the token exchange grant type. Then the authorization server gets the token exchange processor policy specified in the client's configuration.

The token exchange processor policy specifies which parameters from the token exchange request, and optionally which attributes from other sources, will be used. The policy always uses the subject token, but it can use an actor token too. The policy also specifies which token processor instance to use based on the request's subject token type (and actor token type when present). During the transaction, the token processor instance transforms the subject token (and optionally the actor token), parameters, and attributes into a token exchange processor policy attribute contract.

Depending on the type of token requested and what will consume it, the authorization server sends the attribute contract to a token generator instance or access token manager instance to generate the requested token.

This feature uses the protocol defined in the specification for OAuth 2.0 Token Exchange.

A work flow diagram of the OAuth token exchange requests process.