{"id":2996,"date":"2026-02-06T11:16:34","date_gmt":"2026-02-06T02:16:34","guid":{"rendered":"https:\/\/skanto.co.kr\/?p=2996"},"modified":"2026-02-06T11:16:34","modified_gmt":"2026-02-06T02:16:34","slug":"token-exchange","status":"publish","type":"post","link":"https:\/\/skanto.co.kr\/?p=2996","title":{"rendered":"Token Exchange"},"content":{"rendered":"\n

Impersonation vs Delegation<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Bob<\/strong>: a music enthusiast who has meticulously curated a collection of super cool playlists on an online music streaming platform<\/p>\n\n\n\n

Alice<\/strong>: a close friend of Bob\u2019s, who seeks access to his playlists to find the perfect soundtrack for her upcoming road trip<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Alice is impersonating Bob<\/p>\n\n\n\n

    \n
  • The access credentials<\/span> provided to the streaming platform don\u2019t contain any information to recognize Alice\u2019s identity<\/span>.<\/li>\n\n\n\n
  • Whenever Alice accesses the platform, it believes Bob is the one using the service<\/span> although the credentials used by Alice to access the service are different from Bob\u2019s credentials<\/span>.<\/li>\n<\/ul>\n\n\n\n

    The music streaming service has introduced features to support family and friend sharing<\/strong>. Alice can pass her identity information along with the temporary pass provided by Bob<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
      \n
    • The access credentials to the streaming service contain information to recognize Alice\u2019s identity in addition to Bob\u2019s identity<\/span>.<\/li>\n\n\n\n
    • When Alice accesses the service, it distinguishes between Bob and Alice<\/span>, acknowledging Alice as Bob\u2019s agent.<\/li>\n<\/ul>\n\n\n\n

      API Gateway Calls Backend API on Behalf of a Client<\/h2>\n\n\n\n
      \"\"<\/figure>\n\n\n\n

      If you try to use the same token with the BE-API, it won\u2019t work because the token isn\u2019t intended for the BE-API and will be rejected by the BE-API<\/strong> after looking at the audience claim.<\/p>\n\n\n\n

      API-GW to request a new security token suitable for calling the backend API<\/strong> from the IdP by trading the current token sent by the client application.<\/p>\n\n\n\n

      The Token Exchange grant type<\/span> facilitates this exchange, allowing the API-GW to request the audience and request scopes<\/span> from the backend API.<\/p>\n\n\n\n

      In impersonation<\/strong>, the API-GW keeps its identity hidden from the backend API and acts as the end user accessing the API through the client application.<\/p>\n\n\n\n

      In delegation<\/strong>, the backend API recognizes that the API-GW is acting on behalf of the client application<\/span>, which has obtained authorization from the end user.<\/p>\n\n\n\n

      The choice between these approaches depends on the specific design, business and security requirements of the system.<\/p>\n\n\n\n

      Microservice Calls Another Downstream Microservice<\/h2>\n\n\n\n
      \"\"<\/figure>\n\n\n\n

      if you try to use the same token with the Order-Service, it won\u2019t work because the token isn\u2019t intended for the Order-Service<\/strong> and will be rejected by the Order-Service after looking at the audience claim.<\/p>\n\n\n\n

      Upgrading or downgrading the Scope of Security Tokens<\/h2>\n\n\n\n
      \"\"<\/figure>\n\n\n\n

      The principle of elastic privilege<\/h3>\n\n\n\n

      Applications should initially request a token with the minimal scopes<\/strong> required for current functionality, without making assumptions about future functionality<\/strong> that might require additional scopes.<\/p>\n\n\n\n

      Token Exchange becomes practical in such scenarios, allowing the application to obtain the required access token with required scopes when needed.<\/p>\n\n\n\n

      Application Accessing Resources in a Different Trust Domain<\/h2>\n\n\n\n
      \"\"<\/figure>\n\n\n\n

      This is another use case perfectly suited for the Token Exchange grant type. However, compared to previous scenarios, this involves two trust domains<\/strong> and two IdPs<\/strong>, necessitating the existence of a trust relationship between these IdPs<\/strong>.<\/p>\n\n\n\n

      Workload Identity Federation<\/h2>\n\n\n\n
      \"\"<\/figure>\n\n\n\n

      The Token Exchange grant type is very flexible, it lays out request and response messages, along with the message flow. However, it leaves certain crucial aspects open for implementation decisions, such as the supported token types<\/strong> and trust relationships<\/strong>, which are particularly important in cross-domain scenarios<\/strong>.<\/p>\n\n\n\n

      Request, response and the flow<\/h2>\n\n\n\n

      The scenario where token exchange occurs within the same trust domain<\/strong>, facilitated by a single Identity Provider (IdP).<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n
        \n
      • This is an example where an API-GW<\/strong> that is generally recognized as a Resource Server (RS) within the OAuth2 terminology is designated as an OAuth2 client<\/strong> within the context of the Token Exchange. In the bottom line, depending on the circumstance, an entity different from a traditional OAuth2 client (e.g. \u2014 web and mobile apps) can participate in the Token Exchange by playing the client role.<\/strong><\/li>\n<\/ul>\n\n\n\n

        As per the Token Exchange specification, the following parameters are mandatory in the request:<\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n
          \n
        • grant_type<\/strong>: This parameter signals to the IdP that this is a token exchange request.<\/li>\n\n\n\n
        • subject_token<\/strong>: This parameter carries the current token received from the client<\/span>, intended for exchange.<\/li>\n\n\n\n
        • subject_token_type<\/strong>: Denotes the type of the subject token (e.g., OAuth2 access token, OIDC IDToken, or SAML token).<\/li>\n\n\n\n
        • requested_token_type<\/strong>: (Optional) This parameter allows the client application to specify the desired token type<\/span>. In the absence, the IdP may determine the token type based on the application\u2019s configuration.<\/li>\n<\/ul>\n\n\n\n

          While not mandatory, parameters such as audience, resource, and scope<\/strong> are valuable for providing essential information about the target backend service<\/strong> to the IdP. This information helps the IdP identify the appropriate access policy for the target backend<\/strong>.<\/p>\n\n\n\n

          \"\"<\/figure>\n\n\n\n
            \n
          • resource: points to the location of the target, often represented as an HTTP URL.<\/li>\n\n\n\n
          • audience: reserved for the logical name associated with the target, a logical target name recognized by the Identity Provider (IdP).<\/li>\n\n\n\n
          • scope: you can include these scopes within the \u2018scope\u2019 request parameter.<\/li>\n<\/ul>\n\n\n\n

            In the impersonation use case demonstrated above, to employ Token Exchange in delegation, two additional parameters are required:\u00a0actor_token<\/strong><\/em> and\u00a0actor_token_type<\/strong><\/em>. These parameters provide identity information about the party requesting a new token.<\/p>\n\n\n\n

            \"\"<\/figure>\n\n\n\n
              \n
            • actor_token<\/strong>: The token that contains the information related to the identity of the token requesting party.<\/li>\n\n\n\n
            • actor_token_type<\/strong>: Denotes the type of the actor token.<\/li>\n<\/ul>\n\n\n\n

              The specification does not define any specific criteria for subject tokens to be considered valid for the token exchange. Nevertheless, it introduces the\u00a0may_act<\/strong><\/em>\u00a0claim, which an IdP could utilize to ascertain whether the requesting party is authorized to exchange their current subject token for a delegated token. This authorization can be verified by cross-referencing the\u00a0may_act<\/em>\u00a0claim with either the requesting client\u2019s identity or the identity information of the actor token<\/span>.<\/p>\n\n\n\n

              there\u2019s no standardized method for configuring and including\u00a0may_act\u00a0<\/em>in the initial token destined to become the subject token in a subsequent stage.<\/p>\n\n\n\n

              The Token Exchange specification does not impose specific requirements for client registration or client authentication. However, in practical implementations, client authentication, often involving client secrets or other methods, is commonly employed to achieve the desired protection.<\/p>\n\n\n\n

              The Token Exchange response closely resembles standard OAuth2 responses but includes two additional parameters:<\/p>\n\n\n\n

                \n
              • issued_token_type<\/strong>: This parameter signifies the type of the issued token, aligning with parameters like\u00a0requested_token_type<\/code>,<\/em>\u00a0subject_token_type<\/code>,<\/em>\u00a0and\u00a0actor_token_type<\/code><\/em>\u00a0from the request.<\/li>\n<\/ul>\n\n\n\n
                \"\"<\/figure>\n\n\n\n
                  \n
                • token_type<\/strong>: Unlike the previously mentioned parameters, this parameter informs the client how to use the access token to access the target resources. For example, a value of\u00a0Bearer<\/strong>\u00a0indicates that the issued security token can be presented as is, without additional proof of eligibility.<\/li>\n<\/ul>\n\n\n\n

                  the\u00a0access_token<\/strong>\u00a0parameter in the response can be used to return various token types, not limited solely to access tokens. Here is a sample Token Exchange response message which returns an access token.<\/p>\n\n\n\n

                  {\n    \"access_token\": \"eyJ4NXQiOiJOMk5tTUdGbE16UmtPV0l4WXpjNE9XTTNNekl5TURKaVpXVXdZMlF3T0dNeE5ERTVPV1JtWWpRd05EWXlOakkwTkRVM05UTmtZekl4TmpNNFl6RmxaQSIsImtpZCI6Ik4yTm1NR0ZsTXpSa09XSXhZemM0T1dNM016SXlNREppWldVd1kyUXdPR014TkRFNU9XUm1ZalF3TkRZeU5qSTBORFUzTlROa1l6SXhOak00WXpGbFpBX1JTMjU2IiwidHlwIjoiYXQrand0IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIzM2Q5N2NjNS00M2M2LTQ0N2EtODE4Yi0xYWM4MDY2ZjU5ZDIiLCJhdXQiOiJBUFBMSUNBVElPTl9VU0VSIiwiYXVkIjoiXzM4Vm5YS0gyWTNyRDk5M21ZSEpNMWhWQzdVYSIsIm5iZiI6MTY5NTI2MzQ3NywiYXpwIjoiXzM4Vm5YS0gyWTNyRDk5M21ZSEpNMWhWQzdVYSIsIm9yZ19pZCI6Ijc0Y2MwZjJiLWUyMGYtNGQyNy1iYjQ1LTg2YjU0ODFhYWNiYyIsImlzcyI6Imh0dHBzOlwvXC9hcGkuYXNnYXJkZW8uaW9cL3RcL3NhZ2FyYW9yZ1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTY5NTI2NzA3Nywib3JnX25hbWUiOiJzYWdhcmFvcmciLCJpYXQiOjE2OTUyNjM0NzcsImp0aSI6ImM2ZmUyNDZhLWZkMDQtNDQ2Ni1hOGMwLTA4MzczYTMxNGY0MyIsImNsaWVudF9pZCI6Il8zOFZuWEtIMlkzckQ5OTNtWUhKTTFoVkM3VWEifQ.F6v5STHQVTvqsiYbVAbjgdeaj0QgMpkyVvxE5vd3aVUyGD3kNLw-C0ZaekNPDy6i--YKfhYljBKc3gqkO-YbZnpgAbZj7eCxOlNAp_JXqaAlU_sIP30PbCvXLBgLe5mwdJtMSI7NDSQ5nUo4TI_ZZp7HluTZ4nfvKJR1YKltp4D0eQLDCUfiIJHEwsafoAcANKfTbzEtg1vekChdstrakYP9na2xxGYAYZrdJgbUui2CnvfWpxwSRUqybJ_lM-CnrL-XSY70ppTB-y0RpcGtBAN0Usb1631-kbRXLDC8uZwN_pRjDywM5kjzvvrWkJWOuKKXzY1DDBJMEDWhWDWIPw\",\n    \"issued_token_type\": \"urn:ietf:params:oauth:token-type:jwt\",\n    \"token_type\": \"Bearer\",\n    \"expires_in\": 3600\n}<\/code><\/pre>\n\n\n\n
                  Let\u2019s move into a cross-domain use case that we discussed above which involves two different IdPs.<\/p>\n\n\n\n
                  \"\"<\/figure>\n\n\n\n