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

PingFederate can perform the following token exchanges:

  • Access tokens for access tokens
  • ID tokens for access tokens
  • SAML (1.1, 2.0) tokens for access tokens
  • SAML tokens for SAML tokens
  • Kerberos tokens for access tokens
  • Kerberos tokens for SAML tokens
  • X.509 certificate tokens for access tokens
  • X.509 certificate tokens for SAML tokens

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.