OAuth 2.1 規範已經計劃好。讓我們來探索 OAuth 2.0 和 OAuth 2.1 之間的主要差異，以及它們如何在 Logto 中被採用。
自從 OAuth 2.0 (RFC 6749) 於 2012 年推出以來，網頁和移動應用程式的世界已經發生了很大的變化。人們正在從桌面轉向移動設備，單頁應用程式 (SPAs) 現在變得非常流行。我們也看到了許多新的框架和網頁技術的出現。隨著這些變化，安全挑戰也在增加。為了跟上最新的網頁技術，持續發布了像代碼交換的證明密鑰 (PKCE) 這樣的新 RFC 來加強 OAuth 2.0。如今，為了滿足安全需求，將所有最佳實踐統籌變得至關重要，這就是為什麼 OAuth 2.1 即將來臨的原因。
在即將發布的 OAuth 2.1 中，OAuth 工作小組旨在將所有最佳實踐和安全建議匯集成一份文件。在 Logto 中，我們緊跟 OAuth 的最新標準和最佳實踐。在本文中，我們將探討 OAuth 2.0 和 OAuth 2.1 之間的主要差異，以及它們如何在 Logto 中被採用。
OAuth 2.1 中最大的一個變化是所有使用授權碼流的 OAuth 客戶端現在都需要代碼交換的證明密鑰 (PKCE)。PKCE 是一種安全擴展，防止授權碼攔截攻擊。對於無法安全存儲客戶端秘密的移動和單頁應用程式 (SPAs) 特別有用。
根據安全存儲秘密的能力不同，OAuth 客戶端可以分為兩種類型：
機密客戶端：這些客戶端可以安全存儲秘密，比如伺服器呈現的網頁應用程式和網絡伺服器。所有與授權相關的請求都是從伺服器端發出的，暴露客戶端秘密的風險較低。
公開客戶端：這些客戶端無法安全存儲秘密，如移動應用程式和 SPAs。客戶端秘密可以輕易從客戶端代碼中提取，難以保護它不被攻者獲取。
對於公開客戶端，PKCE 是一個必須的安全措施。它確保只有發起授權請求的客戶端才能交換授權碼。
PKCE 的工作原理是生成一個隨機碼的驗證器和基於此驗證器的碼挑戰。驗證器被發送到授權伺服器，碼挑戰用於在交換授權碼以獲取訪問令牌時驗證驗證器。
在 OAuth 2.1 中，PKCE 成為所有使用授權碼流的 OAuth 客戶端的強制要求，無論它們的機密性狀況如何——無論是機密的還是公開的。這一重要的調整確保了對潛在授權碼攔截攻擊的普遍保護。
在 Logto 中，PKCE 驗證流會自動為公開和機密客戶端激活。
對於 SPAs 和移動應用程式，PKCE 是 Logto 中保護授權碼流的必須安全措施。任何缺少碼挑戰的授權請求將會被 Logto 的授權伺服器立即拒絕。
關於機密客戶端（傳統網頁應用程式）為了增強遺留兼容性，Logto 仍然允許授權請求中省略碼挑戰。然而，我們強烈建議機密客戶端遵循公開客戶端的做法，通過在授權請求中整合碼挑戰來採納 PKCE。
重定向 URI（統一資源識別符）是一個具體的端點或網址，授權伺服器在身份驗證和授權過程後將用戶重定向回來。
在 OAuth 流程中，客戶端應用程式在初始授權請求中包含一個重定向 URI。一旦用戶完成身份驗證過程，授權伺服器會生成一個回應，其中包括授權碼，並將用戶重定向回指定的重定向 URI。任何偏離原始重定向 URI 的情況都會導致代碼或令牌洩漏。
重定向 URI 的精確字符串匹配最初在 OAuth 2.0 Security Best Current Practices 第 4.1 節中引入。這一做法確保重定向 URI 必須與授權伺服器註冊的那個完全匹配。任何偏離註冊的重定向 URI 都會導致錯誤回應。
我們已經收到許多社群的請求，要求實現重定向 URI 的通配符匹配。雖然通配符匹配對於管理多個子域或路徑的開發者來說可以提供方便，特別是在擁有大量隨機子域時，但也引入了安全風險，如開放重定向攻擊。關於缺少重定向 URI 驗證的危害的實踐示例，請參考我們的 A brief OAuth security recap 博客文章。
按照 OAuth 2.1 嚴格的安全標準，Logto 使用重定向 URI 的精確字符串匹配。這一決定優先考慮 OAuth 流程的安全性。與其利用通配符匹配，我們鼓勵開發者在 Logto 授權伺服器中註冊所有潛在的重定向 URI。這確保了對重定向 URI 的徹底驗證，有助於減少潛在的安全漏洞。
OAuth 2.0 中的隱式授權流是為了 SPAs 設計的，授權後訪問令牌直接返回到 URL 片段。這種方法很方便，因為它避免了額外的令牌交換步驟，允許客戶端直接接收令牌。
然而，這一方便也帶來了副作用。訪問令牌可能通過瀏覽器歷史記錄、引用頭或其他方式暴露給未授權方，使安全漏洞更易於發生——尤其是在訪問令牌長時間有效的情況下。例如，如果授權請求被惡意方攔截，他們可以輕易地從 URL 片段中提取訪問令牌並冒充用戶。
在 OAuth 2.0 Security Best Current Practices 中明確指出：
客戶端不應使用隱式授權 (回應類型“令牌”) 或其他在授權回應中簽發訪問令牌的回應類型。
因此，隱式流已被正式從 OAuth 2.1 規範中移除。
在 Logto 中，授權碼流帶 PKCE 是唯一支持的 SPAs 和移動應用程式的授權流。授權碼流通過交換授權碼提供了一種更安全的獲取訪問令牌的方式。
資源所有者密碼憑證 (ROPC) 授權允許客戶端用戶名和密碼交換訪問令牌。它在 OAuth 2.0 規範中首次亮相，旨在支持如 HTTP 基本身份驗證或遗留本地應用程式這樣的過時應用程式，這些應用程式無法使用更安全的 OAuth 令牌化流。
由於其安全風險，ROPC 授權類型在 OAuth 2.0 規範中被標記為不推薦使用。用戶的憑證暴露給客戶端應用程式，可能導致潛在的安全漏洞。客戶端應用程式可以存儲用戶的憑證，如果客戶端被攻陷，用戶的憑證可能會暴露給攻者。
在 OAuth 2.0 Security Best Current Practices 第 2.4 節中，進一步強調 ROPC 授權類型的禁用必須不得使用。因此，ROPC 授權類型已從 OAuth 2.1 規範中移除。
由於 ROPC 授權類型存在高安全風險，Logto 從未支持過它。如果你仍在你的遺留應用程式中使用直接用戶憑證流，我們強烈建議遷移到更安全的方法，如授權碼流或客戶端憑證授權。Logto 提供各種 SDK 和教程，幫助你輕鬆將這些安全的 OAuth 流整合到你的應用程序中。
我們理解開發者可能希望設計或自行託管自己的用戶登錄界面，以獲得最佳產品體驗。在 Logto 中，我們提供一系列登錄體驗 (SIE) 定制選項，包括品牌設置和自定義 CSS。此外，我們還有若干進行中的項目，如自帶 UI 和直接登錄，為開發者提供更多彈性，以在保持 OAuth 流程安全的同時，自帶他們自己的登錄界面。
OAuth 2.1 是最新的 OAuth 升級，旨在應對當今的安全挑戰，並迎合現代網頁和移動應用程式的需求。OAuth 工作小組正在積極更新和完善 OAuth 2.1，以確保它符合最新的安全標準和最佳實踐。最新版草案 OAuth 2.1 11 於 2024 年 5 月發布，標誌著其走向最終定稿的重要進展。隨著各種採用的廣泛應用即將到來，我們強烈建議大家遵循 OAuth 2.1 中概述的最佳實踐，以增強安全性和改善用戶體驗。