Configure token exchange

You can add a trusted token issuer to exchange tokens received from the configured third-party issuer for WSO2 Identity Server tokens.

Learn how to configure the OAuth 2.0 token exchange flow in your WSO2 Identity Server organization. Refer Token exchange grant for more information on how the flow works.

Follow this guide for instructions.

Register a trusted token issuer

To exchange a third-party token for an WSO2 Identity Server token, you need to register the third-party token issuer as a trusted token issuer in your WSO2 Identity Server organization.

To register a trusted token issuer:

1. On the WSO2 Identity Server console, go to Connections.
2. Click New Connections and click Create on the Trusted Token Issuer.

3. Enter the following details of the trusted token issuer:

   Parameter	Description
   Trusted token issuer name	A unique name for the new trusted token issuer.
   Issuer	A unique issuer value of the trusted token issuer. This is the value of the iss claim in the JWT token generated from the configured identity provider. Example: https://third-party-token-issuers.io/oauth2/token
   Alias	The name by which the trusted token issuer knows WSO2 Identity Server. The aud claim of the token should include the WSO2 Identity Server organization's issuer value. If the aud claim doesn't include the organization's issuer value, the system validates the alias value you assign here against the aud claim.

4. Click Next and provide the mode of certificate configuration.

   • JWKS endpoint: The JWKS endpoint of the trusted token issuer.

     Note

     For JWKS endpoints, the default read timeout equals 1000 milliseconds. To modify this value, add the following parameter to the deployment.toml file in the <PRODUCT_HOME>/conf/repository directory.

     [oauth.jwks_endpoint]
     read_timeout = <value in milliseconds>
     

   • Use PEM certificate: Upload or paste the public certificate of the trusted token issuer. The certificate should be in PEM format.

     If you have a certificate in other formats such as .crt, .cer or .der, expand here to see how you can convert them to PEM format using OpenSSL

     Convert CRT to PEM

     openssl x509 -in cert.crt -out cert.pem
     

     Convert CER to PEM:

     openssl x509 -in cert.cer -out cert.pem
     

     Convert DER to PEM:

     openssl x509 -in cert.der -out cert.pem
     

5. Click Finish to add the new trusted token issuer.

Enable token exchange in your app

Before you begin

You need to register any one of the following application types with WSO2 Identity Server:

• Standard-based OIDC application
• Mobile application
• Traditional OIDC web application

Currently, WSO2 Identity Server does not support the token exchange grant for single-page applications.

To enable token exchange in your application:

1. On the WSO2 Identity Server Console, go to Applications.

2. Open your application from the list and go to the Protocol tab.

3. Add Token Exchange under the Allowed grant types.

   Note

   To enable refresh tokens for the token exchange grant, include Refresh Token as an Allowed Grant Type. Learn more about how the refresh token grant type works.

4. Click Update to save the configurations.

Configure token exchange for a local user

WSO2 Identity Server can exchange a third-party token with a token issued for an existing local user account. This is beneficial if you wish to check for blocked/disabled user accounts or to enforce Role-Based Access Control (RBAC).

You can use the following properties to customize how token exchange occurs for identities with local user accounts.

Prioritize local account attributes

After enabling this configuration, WSO2 Identity Server includes the local user profile information in the exchanged token if the federated identity has a linked local user account. Otherwise, WSO2 Identity Server returns the profile information received directly from the federated identity.

To prioritize linked local account attributes:

1. On the WSO2 Identity Server console, go to Applications.

2. Open your application from the list and go to its User Attributes tab.

3. Scroll down and under Attribute Resolution for Linked Accounts, select Use linked local account attributes.

   Note

   Select Require linked local account for WSO2 Identity Server to return an error when it can't find a user account linked to the federated identity.

Implicit account linking

You can use implicit account linking capability in the registered trusted token issuer to automatically create an account link between a local user account in WSO2 Identity Server and a federated identity during token exchange.

You can configure lookup attributes to search for a matching local user account. If the system finds a matching account, WSO2 Identity Server automatically links the local user account to the federated identity.

After establishing account links, administrators can't delete them. Users can manage their own accounts links using the Manage linked accounts capability in the Self-service portal.

Important

When configuring implicit account linking, select lookup attributes (such as email, username, or externalId) that are unique across all user stores. This prevents failures when multiple accounts match the same attribute.

Note

WSO2 Identity Server skips implicit account linking when Require linked local account is disabled, even if the implicit linking option remains enabled.

To enable implicit account linking,

1. On the WSO2 Identity Server console, go to Connections.

2. Open the trusted token issuer you configured above and go to its Advanced tab.

3. Select Implicit account linking.

4. Select the primary attribute for WSO2 Identity Server to perform the lookup.

5. Optionally, select a secondary attribute for WSO2 Identity Server to perform the lookup.

   Warning

   Ensure that the chosen lookup attributes undergo verification by the third-party token issuer. If unverified, malicious users can manipulate attributes to gain access to local accounts that don't belong to them.

Note

If WSO2 Identity Server can't find a matching local user account using the primary lookup attribute, it searches for matching accounts using the secondary lookup attribute.

By default, the username attribute is available as a lookup attribute. Administrators can make an attribute unique across the user stores, after which it will appear in the lookup attributes list.

WSO2 Identity Server will look for the mapped OpenID Connect attribute in the third-party token.

Try it out

Follow the steps given below.

1. Obtain the JWT token received from the third-party token issuer.

2. Execute the following cURL command to exchange the third-party token for an WSO2 Identity Server token.

   curl --location 'https://localhost:9443/oauth2/token'
   --header 'Content-Type: application/x-www-form-urlencoded'
   --header 'Authorization: Basic <base64 Encoded (clientId:clientSecret)>'
   --data-urlencode 'scope=<desired scopes>'
   --data-urlencode 'subject_token=<jwt_token>'
   --data-urlencode 'subject_token_type=urn:ietf:params:oauth:token-type:jwt'
   --data-urlencode 'requested_token_type=urn:ietf:params:oauth:token-type:access_token'
   --data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange'
   

   Note

   WSO2 Identity Server only copies the sub claim from the token received from the trusted token issuer to the exchanged WSO2 Identity Server token.

   Note

   To learn how token exchange can be invoked in organization applications, see Generate tokens for organization applications.

Upon successful execution, you will receive the exchanged token.