Token Exchange is a service that is specified in RFC 6893 (Draft).
The Token Exchange service is able to receive and validate security tokens and issue new security tokens in response.
This exchange of security tokens may serve many different purposes:
The client may obtain a security token valid in another security domain (i.e., different signing keys).
The security token may contain different claims (i.e., the sub-claim may use the value of a different claim, different audience or scopes).
Token Exchange may be used in delegation and impersonation use cases.
Use Case Scenarios
The following picture shows a typical use case scenario where a separate Token Exchange server (Standalone OAuth AS) is deployed to service a number of different security domains.
In this scenario, we find a number of security zones (frontend zones in blue) that are exposed to the Internet to service clients used by end users. These zones could be different sales organizations or different geographical websites.
The services in the different frontend security zones connect to a number of central services zones (Backend in red and green). These zones could be a centralized billing or a centralized order management component.
In the drawing, the following elements are shown:
Security zones
The use case shows different security zones in different colors.
Blue: Several security zones that allow end user clients to obtain security tokens from a shared authorization server (FE OAuth AS).
Red / Green: Two security zones that require security tokens that are only valid in their respective zones.
Security Tokens
Blue: Security Tokens that are valid only within the blue security zones. The blue tokens are issued to clients in the User zone.
Red / Green: Tokens that are valid only in their respective zones. The tokens are issued by the Token Exchange Server (Standalone OAuth AS).
Token Exchange
The Token Exchange Server (Standalone OAuth AS) will receive requests from servers in the blue zone with blue tokens as subject token.
The Token Exchange server will issue either red or green tokens depending on the audience or resource information in the request.
PEP (Policy Enforcement Point)
The policy enforcement points (PEP) in these zones validate the tokens using the key material from either the FE OAuth AS (blue zone) or the Token Exchange Server (red and green zones).
Each PEP will only validate the tokens of its own security zone.
Client
The authorization server of the blue zone will only accept eduser clients requesting security tokens. Typical token requests in this zone will use the Authorization Code Flow.
The Token Exchange server (Standalone OAuth AS) will only accept servers from the blue zones as clients. On such servers will be able to obtain exchanged tokens.
Alternative use case scenarios:
Integrated deployment
In an integrated use case scenario, the Token Exchange server is deployed directly on the authorization server.
This scenario is used to minimize the number of installations of Airlock IAM. On the downside, the security segregation between clients connecting to the authorization server and clients connecting to the Token Exchange server is no longer possible.
Segregated deployment
In a segregated use case scenario, every security domain hosts its own Token Exchange server.
This scenario is the most secure since each Token Exchange server tightly controls which clients are allowed to connect and it manages its own keys to issue tokens. The price for the security gain is both deployment costs (additional Token Exchnage servers) and increased configuration complexity.
Note that in this scenario the Frontend Servers must be able to request tokens from different Token Exchange servers based on the audience or resource configuration.
Token Exchange Properties
Client
In the context of a Token Exchange, the system that sends a request to the Token Exchange endpoint is considered the client.
This may be a different system from the client that obtained the original token.
Client authentication
Token Exchange is implemented as an additional grant of the standard authorization server and therefore supports all the client authentication methods available.
Subject token
In the request, the client presents the subject token to the Token Exchange service.
As subject tokens the authorization server currently supports only JWT tokens.
Examples are:
access token
ID token
Opaque access tokens are not supported.
Validation of subject token
The token exchange server will validate the subject token locally and retrieve the key material through OIDC discovery from the AS that issued the subject token.
If the retrieval of the key material or the validation of the signature fails, the token exchange will immediately fail.
Token introspection endpoint
The Token Exchange server does not provide a token introspection endpoint.
Token Revocation
The Token Exchange server does not support token revocation.
User interaction
Token Exchange is a non-interactive exchange of security tokens. It is not possible to interact with the user.
Known Limitations
This implementation of Token Exchange service has the following known limitations.
The Token Exchange server will:
only accept JWT tokens.
only issue access tokens (JWT).
only work with subject tokens issued by an OpenID Provider.
not use token introspection to validate the subject token. As a consequence, it is possible to exchange revoked subject tokens.
