了解 OAuth/OIDC 中的令牌交換

在 RFC 8693 中引入，令牌交換是允許受信任的客戶端交換現有令牌以獲得具有不同屬性或範圍的新令牌的一種 OAuth 擴展。這個機制對於服務、應用程序或終端用戶來說特別有用，可以通過預先授權的令牌獲取正常的 OAuth 訪問令牌，而無需經過完整的 OAuth 流程。

與授權碼流程的比較#

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

這是令牌交換流程：

重定向#

主要的區別在於，在授權碼流程中，客戶端應用程序將用戶重定向到授權伺服器以獲取訪問令牌。而在令牌交換中，客戶端應用程序可以在不涉及用戶重定向的情況下與授權伺服器交換令牌。

這是因為在授權碼流程中，客戶端應用程序不是“受信任的”，需要知道用戶的憑證才能獲得訪問令牌。而在令牌交換中，客戶端應用程序被信任已經從用戶那裡獲得了令牌，並且授權伺服器將驗證令牌並簽發新令牌。

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

在令牌交換流程中，“Auth Server” 現在有兩個參與者：

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

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

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

令牌交換流程可以在不需要用戶互動的情況下進行，這在以下場景中很有用：

• 模擬： 允許服務（例如，後端微服務）或管理員用戶代表用戶執行操作，而不暴露完整的用戶憑證。
• 自動化： 允許受信任的服務自動執行操作，而無需人工干預，或進行自動化測試。
• 與其他 IdP 的集成： 在不同身份系統之間翻譯令牌，以維護無縫的用戶體驗並有效管理權限，一個常見場景是將 SSO 令牌翻譯為下游服務的令牌。
• 遷移： 將令牌從一個授權伺服器遷移到另一個，例如，從遺留系統遷移到現代 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: 可選。訪問令牌的受眾，表示令牌的預期接收者，授權伺服器可能會使用 resource 的值，如果沒有指定 audience。
6. scope: 可選。請求的範圍。

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

這是一個請求的示例：

Logto 中的令牌交換#

Logto 默認支持令牌交換，包括 模擬 和 個人訪問令牌。