了解 OAuth/OIDC 中的令牌交換

在 RFC 8693 中介紹的令牌交換是一個 OAuth 擴展, 允許受信任的客戶端將現有令牌交換成具有不同屬性或範圍的新令牌。這種機制特別適用於服務、應用程序或終端使用者通過預授權令牌獲取普通 OAuth 訪問令牌，而不需要執行完整的 OAuth 流程。

與授權碼流程的比較#

首先，讓我們看一下 OAuth 授權碼流程，這是獲取訪問令牌的最常見流程。

這是令牌交換流程：

重定向#

主要的區別在於，在授權碼流程中，客戶端應用程序會將用戶重定向到授權服務器以獲取訪問令牌。而在令牌交換中，客戶端應用程序可以與授權服務器交換令牌，無需用戶參與重定向。

那是因為在授權碼流程中，客戶端應用程序是“不可靠的”，需要知道用戶的憑證才能獲取訪問令牌。在令牌交換中，客戶端應用程序被信任已經從用戶那裡獲得令牌，授權服務器會驗證該令牌並發行新令牌。

令牌發行者和令牌交換服務#

在令牌交換流程中，“Auth Server” 現在有兩個角色：

1. 令牌發行者：向客戶端應用程序發行主題令牌。
2. 令牌交換服務：驗證主題令牌並向客戶端應用程序發行新令牌。

令牌交換服務與在授權碼流程中的“Auth Server”相同，而令牌發行者可以是第三方身份提供者，也可以從“Auth Server”拆分出來作為專門服務。

什麼時候使用令牌交換？#

令牌交換流程可以無需用戶交互進行，這在以下場景中很有用：

• 模仿： 允許服務（例如，後端微服務）或管理員用戶在不暴露完整用戶憑證的情況下代表用戶執行操作。
• 自動化： 允許受信任的服務自動執行操作而無需人工干預，或者執行自動化測試。
• 與其他 IdP 集成： 跨不同身份系統翻譯令牌以保持無縫的用戶體驗並有效地管理權限，一個常見的場景是將單一簽入令牌翻譯為下游服務的令牌。
• 遷移： 將令牌從一個授權服務器遷移到另一個，例如從舊系統遷移到現代化的 OAuth/OIDC 相容系統。

令牌交換過程#

交換新訪問令牌是最常見的使用案例，我們以此為例。不僅限於訪問令牌，令牌交換還可以用來發行其他類型的令牌，如刷新令牌、ID 令牌等。

客戶端應用程序#

要進行令牌交換，需要在授權服務器註冊的客戶端應用程序。

並且客戶端應用程序在發起令牌交換流程之前必須有一個 subject_token，這個令牌通常由授權服務器或可信第三方身份提供者授予。通過擁有這個令牌，客戶端應用程序現在可以被“信任”地交換令牌，而無需用戶的憑證和互動。

令牌交換請求#

客戶端發送請求到授權服務器的令牌端點以交換現有令牌。這包括 subject_token（被交換的令牌）和可選的，所需的目標受眾、範圍和令牌類型。

1. grant_type: 必須。此參數的值必須為 urn:ietf:params:oauth:grant-type:token-exchange，表示正在執行令牌交換。
2. subject_token: 必須。用戶的 PAT。
3. subject_token_type: 必須。在 subject_token 參數中提供的安全令牌的類型。此參數的一個常見值是 urn:ietf:params:oauth:token-type:access_token，但可以根據交換的令牌進行變化。
4. resource: 可選。資源指標，幫助指定訪問令牌的目標資源。
5. audience: 可選。訪問令牌的受眾，指示令牌的預期接收者，如果未指定 audience，授權服務器可以使用 resource 的值。
6. scope: 可選。請求的範圍。

此外，請求需要包括客戶端信息，可以編碼為基本身份驗證標頭或作為表單數據發送。

以下是一個請求範例：

在 Logto 中的令牌交換#

Logto 支援開箱即用的令牌交換，包括模仿和個人訪問令牌。