前言

上一篇介紹的 SAML 2.0 Bearer，是將既有的 SAML Assertion 送到 Token 端點交換 Access Token。今天要看的 **Token Exchange（RFC 8693）進一步放寬輸入與輸出的 Token 類型，並明確區分模擬（Impersonation）與委派（Delegation）**兩種語意。實際可交換的 Token 類型，仍取決於 Authorization Server 的支援與安全政策。

需要特別說明的是，Token Exchange 並不屬於 JWT Bearer 與 SAML 2.0 Bearer 所採用的身份聲明框架，而是由 RFC 8693 獨立定義的 OAuth 2.0 擴展機制。三者都能運用既有憑證或 Token 取得新的 Access Token，但規格架構不同。

今天內容涵蓋:

1. Token Exchange 要解決的問題
2. 核心參數
3. Impersonation 與 Delegation 的運作方式
4. Token Exchange 與 JWT／SAML Bearer 的差異

一、Token Exchange 要解決的問題

以微服務架構為例，使用者先以 aud=service-a 的 Access Token 呼叫服務 A，之後服務 A 需要代表使用者呼叫服務 B。此時，服務 A 不應直接將原始 Token 轉送給服務 B，因為可能遇到以下問題：

• aud 指向服務 A，服務 B 因此拒絕接受。
• scope 不符合服務 B 的需求，可能權限不足，也可能授權範圍過大。
• 服務 B 不支援原始 Token 的類型。
• 原始 Token 無法清楚呈現服務 A 曾經參與這次呼叫，造成稽核紀錄不完整。

這表示一個 Token 即使仍然有效，也不一定適合直接拿去呼叫其他服務。

Token Exchange 提供的解法，是讓服務 A 將原始 Token 交給 Authorization Server，並指定準備存取的目標服務與所需權限。Authorization Server 驗證原始 Token、Client 身份與交換政策後，再核發一個適合服務 B 使用的新 Token。新 Token 可以採用不同的 aud、scope 與有效期限，並在委派情境中保留實際代為操作的服務身份。

這個流程可以拆成兩項工作：

• Token 發行者（Token Issuer）：先向 Client 核發原始 Token；這個原始 Token 稱為主體 Token（Subject Token）。
• Token 交換服務（Token Exchange Service）：接收並驗證 Subject Token，再根據目標服務的需求核發新 Token。

前者負責「發出原始 Token」，後者負責「用原始 Token 換取新 Token」。這兩項工作可以由同一個 Authorization Server 處理，也可以由不同系統分別負責。

圖中的流程可依下列順序理解：

1. 取得原始 Token：Token Issuer 向 Client 核發 Subject Token。
2. 提出交換請求：Client 將 Subject Token 傳送至 Token Exchange Service，並指定目標服務、資源或所需權限。
3. 執行驗證：Token Exchange Service 驗證原始 Token、Client 身份及交換政策，確認這次交換是否被允許。
4. 核發新 Token：驗證成功後，Token Exchange Service 回傳適合目標服務使用的新 Token；Client 再以新 Token 呼叫目標 API。

整體而言，Token Exchange 不是把原始 Token 原封不動轉交給下一個服務，而是依目標服務的驗證條件與權限需求，重新核發更適合的新 Token。

二、核心參數

Token Exchange Request 的目的，是將原始 Token 交給 Authorization Server，並說明新 Token 要用在哪裡、需要哪些權限。為了方便理解，可以將參數分成「基本交換」與「委派時額外使用」兩組。

基本交換的參數

委派時額外使用的參數

如果服務 A 是代表使用者發起交換，還需要區分兩個身份：

• subject_token：使用者的 Token，表示「為了誰執行」。
• actor_token：服務 A 的 Token，表示「實際由誰執行」。

只提供 subject_token 時，屬於 Impersonation；同時提供 subject_token 與 actor_token 時，則屬於 Delegation。提供 actor_token 時，也必須使用 actor_token_type 說明它的 Token 類型。下一節會進一步說明兩種方式的差異。

三、Impersonation 與 Delegation 的運作方式

先釐清一件事：Impersonation 與 Delegation 是同一層級的兩種 Token Exchange 方式，不是前後兩個步驟。 兩者差別在於新 Token 是否保留服務 A 的身份。

Impersonation（模擬）

Impersonation 是讓服務 A 以使用者的身份呼叫服務 B。依照圖中的編號，完整流程如下：

1. 持有原始 Token： 服務 A 已經持有代表使用者的原始 Access Token。
2. 送出 Token Request： 服務 A 將 subject_token 與 subject_token_type 送到 Token Exchange Service，並透過 audience 或 resource 指定服務 B。此處不提供 actor_token；圖中的 client_id 與 client_secret 則用來示意 Client Authentication。
3. 驗證交換條件： Token Exchange Service 驗證服務 A 的 Client 身份、Subject Token，以及交換政策，確認這次交換是否被允許。
4. 核發新 Token： 驗證成功後，Token Exchange Service 核發適用於服務 B 的新 Access Token。這個 Token 代表使用者，但不記錄服務 A 的身份。
5. 回傳 Token Response： Token Exchange Service 將新 Token、Token 類型與有效期限等資訊回傳給服務 A。
6. 呼叫服務 B： 服務 A 使用新 Token 請求服務 B 的受保護資源。
7. 驗證新 Token： 服務 B 驗證新 Token 的簽章、有效期限、使用對象與權限。
8. 回傳受保護資源： 驗證通過後，服務 B 將請求結果回傳給服務 A。

對應的 Request 只帶入 subject_token：

POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange&
audience=urn%3Aexample%3Acooperation-context&
subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0...&
subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

重點是服務 A 並未直接轉送原始 Token，而是先換得適合服務 B 使用的新 Token；只是新 Token 不會記錄服務 A 的身份。因此，Impersonation 適合服務 B 只需辨認使用者的情況，例如相容舊系統；相關系統仍須另外保存稽核日誌。

💡服務 B 是否能辨認服務 A？

• Client Authentication： 讓 Authorization Server 知道請求來自服務 A。
• actor_token： 讓服務 B 從新 Token 得知，實際代為操作的是服務 A。

Impersonation 只有第一項，所以 Authorization Server 知道服務 A 是誰，但服務 B 不知道。

Delegation（委派）

Delegation 會在新 Token 中保留服務 A 的身份。依照圖中的編號，完整流程如下：

1. 持有原始 Token： 服務 A 已經持有代表使用者的原始 Access Token。
2. 送出 Token Request： 服務 A 將使用者的 subject_token 與自己的 actor_token 送到 Token Exchange Service，並透過 audience 或 resource 指定服務 B。
3. 驗證交換條件： Token Exchange Service 驗證服務 A 的 Client 身份、Subject Token、Actor Token 與交換政策。
4. 核發新 Token： 驗證成功後，Token Exchange Service 核發適用於服務 B 的新 Access Token。這個 Token 代表使用者，並保留服務 A 的身份。
5. 回傳 Token Response： Token Exchange Service 將新 Token、Token 類型與有效期限等資訊回傳給服務 A。
6. 呼叫服務 B： 服務 A 使用新 Token 請求服務 B 的受保護資源。
7. 驗證新 Token： 服務 B 驗證新 Token 的簽章、有效期限、使用對象與權限。
8. 回傳受保護資源： 驗證通過後，服務 B 將請求結果回傳給服務 A。

對應的 Request 會比 Impersonation 多出 actor_token 與 actor_token_type：

POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange&
subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0...&
subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token&
actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjgiLCJ0eXAiOiJKV1QifQ...&
actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

Request 中的 actor_token 會讓新 Token 保留服務 A 的身份，通常記錄在 act Claim。服務 B 看到後，就知道：「這是使用者的操作，但實際由服務 A 代為送出。」

Delegation 適合需要追蹤實際呼叫者的微服務系統；若服務 B 無法處理服務 A 的身份，才改用 Impersonation。

交換成功後的回應

兩種方式交換成功後，都會取得新的 Token，例如：

{
  "access_token": "eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIn0...",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 3600
}

其中，issued_token_type 用來說明實際核發的 Token 類型；此範例核發的是 Access Token。

兩種方式的差異

實際應用範例

• Kubernetes 程式存取雲端資源： Kubernetes 裡的程式拿 Service Account Token（代表程式自己的身份），換成雲端平台接受的短效憑證。因為整個過程只有「程式自己」一個身份，沒有服務代替使用者操作，所以不屬於 Impersonation 或 Delegation。
• 客服協助排查問題（Impersonation）： 客服人員經過授權後，暫時以使用者身份重現操作畫面，系統則另外記錄模擬者、時間與原因。
• 電商訂單處理（Delegation）： 使用者向訂單服務送出訂單後，訂單服務代表使用者呼叫付款服務；新 Token 同時保留使用者與訂單服務的身份，方便付款服務進行授權與稽核。

四、Token Exchange 與 JWT／SAML Bearer 的差異

JWT Bearer 與 SAML 2.0 Bearer 都依循身份聲明框架（Assertion Framework），分別使用 JWT 與 SAML Assertion 交換 Access Token。Token Exchange 則是由 RFC 8693 獨立定義的擴展機制，可在 Authorization Server 支援的範圍內接受不同類型的 Token，並依目標服務重新核發 Token。

三者可以搭配使用。例如，Client 可先以 SAML 2.0 Bearer 將 SAML Assertion 換成第一個 Access Token；當該 Token 需要在微服務之間繼續傳遞時，再透過 Token Exchange 取得適合下游服務的新 Token，並保留必要的委派紀錄。

小結

Token Exchange 的核心，是用現有 Token 換取另一顆用途更合適的新 Token。 新 Token 可以指定使用對象、權限與有效期限，再由 Client 用來存取目標服務。

本文可整理成三個重點：

• Token Exchange 的基本動作是「用一顆 Token 換另一顆 Token」，交換前後可以代表同一個身份，不一定涉及模擬或委派。
• 新 Token 可依目標服務調整使用對象、權限與有效期限；實際支援的 Token 類型則由 Authorization Server 決定。
• 當服務 A 代表使用者呼叫服務 B 時，才需要區分 Impersonation 與 Delegation：前者只讓新 Token 代表使用者，後者還會保留服務 A 的身份，方便服務 B 授權與稽核。

下一篇將介紹 Implicit Grant。這是 OAuth 2.0 早期為純前端應用設計的授權流程，但因 Access Token 會直接回傳至前端，面臨較高的外洩風險，目前已不再建議使用。

參考資源

• RFC 8693: OAuth 2.0 Token Exchange - RFC Editor
• RFC 8693 - OAuth 2.0 Token Exchange - IETF Datatracker
• OAuth 2.0 Token Exchange - oauth.net
• The Many Faces of OAuth 2.0 Token Exchange - Auth0
• OAuth 2.0 Token Exchange (RFC 8693): Impersonation & Delegation - ZITADEL Docs
• OAuth 2.0 Token Exchange - Safewhere Identify