oauth 2.0oidc

不透明令牌 (Opaque token) 是什麼？

不透明令牌是一個隨機的、唯一的字串，對客戶端來說沒有意義，但作為參考鍵用於在伺服器的資料庫中查找授權數據。

什麼是不透明令牌 (Opaque token)？

不透明令牌是一個隨機的、唯一的字串，對客戶端來說沒有意義，但作為參考鍵用於在伺服器的資料庫中查找授權數據。

不透明令牌通常使用密碼學安全的偽隨機數生成器生成，以確保其不可預測性和安全性，其格式由其 issuer 決定。

以下是一個不透明令牌的例子：

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

JWT (JSON Web Token) 和不透明令牌的區別是什麼？

主要區別在於這些令牌如何處理和驗證授權信息：

不透明令牌是一個不包含任何信息的隨機字串。伺服器必須查詢其後端資料庫以檢索與此令牌相關的任何授權數據。這使得不透明令牌完全依賴於授權伺服器進行驗證和解釋。

JWT 是一個自包含的令牌，內部攜帶所有必要的信息。

以下是一個 JWT 的例子，它是一個 base64 編碼的字串：

eyJhbGciOiJIUzI1NiIs.eyJzdWIiOiIxMjM0NTY3O.SflKxwRJSMeKKF2QT4f

它包含三個由點分隔的部分：

Header - 包含有關令牌類型和用於簽名的算法的信息。例如，{"alg": "HS256", "typ": "JWT"}。
Payload - 包含 claim（聲明）——有關用戶或授權的信息，如用戶 ID、過期時間和 scope。任何人都可以解碼它以查看 claim，因為它是編碼的但未加密。
Signature - 通過結合 header、payload 和一個秘密密鑰使用指定的算法生成。此簽名用於驗證令牌的完整性並確保其未被篡改。

這種結構允許 JWT 在不查詢資料庫的情況下進行驗證和使用。

有關 JWT 的更多詳細信息，請參閱 JSON Web Token (JWT) 。

並查看 Opaque token vs JWT 以更深入地了解它們的區別。

如何驗證不透明令牌

在簡單的系統中，不透明令牌驗證通常由伺服器直接處理，伺服器使用不透明令牌作為鍵查詢資料庫以檢索相關的授權信息。

在引入 OAuth 2.0 的多方系統中，多個資源伺服器（參見：資源伺服器 (Resource server) ）可能需要驗證相同的不透明令牌。OAuth 2.0 提供了一個標準化的 token introspection 機制來進行此驗證：

有關 token introspection 的詳細信息，請參閱權杖內省 (Token introspection) 。

不透明令牌在 OIDC 中如何使用？

在 OIDC ( OpenID Connect (OIDC) ) 的上下文中，不透明令牌在不同場景中具有特定用途：

用戶資料檢索

默認情況下，當客戶端請求一個不指定資源的 access token 並包含 openid scope 時，授權伺服器會發出一個不透明的 access token。此令牌主要用於從 OIDC /oidc/userinfo 端點（參見： Userinfo 端點 (Userinfo endpoint) ）檢索用戶資料信息。

Refresh token 交換

Refresh token（參見：更新令牌 (Refresh token) ）通常作為不透明令牌發行，因為它們僅在客戶端和授權伺服器之間交換。當當前的 access token 過期時，客戶端可以使用不透明的 refresh token 獲取新的 access token，而無需重新驗證用戶。

不透明令牌的優缺點是什麼？

優點

安全性：不透明令牌非常適合處理敏感數據，如 refresh token。由於內容完全隨機且無意義，即使有人攔截了令牌，他們也無法提取任何有用的信息。這使得它們在高安全性場景中尤其有價值，如銀行交易或處理敏感用戶數據。
可撤銷性：伺服器可以隨時立即使不透明令牌失效。這在需要快速移除用戶訪問時特別有用。與 JWT 在過期前保持有效不同，不透明令牌可以立即撤銷（參見： JWT 的限制）。
大小：不透明令牌通常比 JWT 短得多。這種較小的大小減少了網絡帶寬使用和存儲需求。在頻繁傳輸令牌的系統中，如移動應用或物聯網設備，這一優勢尤為明顯。
簡單性：不透明令牌的實現非常簡單。你生成一個隨機字串並將其與相關數據一起存儲。無需像 JWT 那樣處理複雜的加密或簽名驗證。這種簡單性使它們非常適合內部系統認證。

缺點

有狀態：每個不透明令牌都需要在伺服器端存儲。這在分佈式系統中增加了額外的複雜性，因為令牌數據必須在多個伺服器之間同步。例如，如果你有多個認證伺服器，它們都需要訪問相同的令牌資料庫或緩存系統以正確驗證令牌。
性能：令牌驗證總是需要資料庫查詢或 API 調用。在高流量系統中，這些額外的資料庫查詢可能會造成性能瓶頸。例如，如果你的系統每秒處理數千個請求，每個請求都需要令牌驗證，則額外的資料庫負載會變得顯著。
互操作性：不同系統可能以不同方式實現不透明令牌。這在與第三方服務或不同授權伺服器合作時可能會造成整合挑戰。雖然像 OAuth 2.0 token introspection 這樣的標準有幫助，但當系統使用不同的令牌格式或驗證方法時，你仍可能遇到兼容性問題。