OAuth 2.1 是來了：你需要知道的事情

介紹#

自從 OAuth 2.0 (RFC 6749) 在 2012 年推出以來，網頁和行動應用的世界已經發生了很大的變化。人們越來越多地從桌面轉向移動設備，而單頁應用程序 (SPAs) 現在也很受歡迎。我們還看到很多新框架和網頁技術出現。隨著這些變化，安全挑戰也不斷增加。為了跟上最新的網頁技術，新的 RFC，如 Proof Key for Code Exchange (PKCE)，不斷被發布以增強 OAuth 2.0。將當今的安全需求的所有最佳做法聚集在一起變得至關重要，這就是為什麼 OAuth 2.1 即將到來的原因。

在即將到來的 OAuth 2.1 中，OAuth 工作組旨在將所有最佳做法和安全建議整合到一個文檔中。在 Logto，我們不斷擁抱 OAuth 的最新標準和最佳做法。在本文中，我們將探討 OAuth 2.0 和 OAuth 2.1 之間的主要差異，以及它們如何被採納到 Logto 中。

PKCE 現在對所有使用授權碼流程的 OAuth 客戶端是必須的#

在 OAuth 2.1 中，最重要的變化之一是 Proof Key for Code Exchange (PKCE) 現在是所有使用授權碼流程的 OAuth 客戶端的要求。PKCE 是一個安全擴展，可防止授權碼攔截攻擊。它對於移動應用和單頁應用程序（SPAs）特別有用，因為在這裡客戶端密鑰無法安全存儲。

根據它們安全存儲密鑰的能力，可以將 OAuth 客戶端分為兩種類型：

1. 機密客戶端：這些客戶端可以安全地存儲密鑰，例如服務器渲染的網頁應用程序和網絡服務器。所有與授權相關的請求都由服務器端發起，暴露客戶端密鑰的風險較低。

2. 公開客戶端：這些客戶無法安全存儲密鑰，例如移動應用和單頁應用。客戶端密鑰可以很容易地從客戶端代碼中提取，並且很難防止攻擊者。

對於公開客戶端，PKCE 是必需的安全措施。它確保只有發起授權請求的客戶端才能交換授權碼。

PKCE 通過生成隨機代碼驗證器和基於代碼驗證器的代碼挑戰來工作。代碼驗證器被送往授權服務器，並且在交換授權碼為訪問令牌時代碼挑戰用於驗證代碼驗證器。

在 OAuth 2.1 中，PKCE 對所有使用授權碼流程的 OAuth 客戶端無論其機密性狀態（無論是機密還是公開）都變得強制性。這一關鍵調整確保了對潛在授權碼攔截攻擊的普遍保護。

在 Logto 中，PKCE 驗證流程會自動激活對於公開和機密客戶端。

對於 SPAs 和移動應用來說，PKCE 是保護 Logto 中授權碼流程的必需安全措施。任何缺乏代碼挑戰的授權請求都會被 Logto's 授權服務器迅速拒絕。

關於機密客戶端（傳統網頁應用），為了增強傳統兼容性，Logto 仍允許在授權請求中省略代碼挑戰。但我們強烈倡導機密客戶端在授權請求中採用 PKCE 並包含代碼挑戰，跟隨公開客戶端的做法。

Redirect URIs 精確匹配#

Redirect URI（統一資源標識符）是授權服務器在身份驗證和授權過程後將用戶重定向回的特定端點或 URL。

在 OAuth 流程中，客戶應用程序在初始授權請求中會包含一個 Redirect URI。用戶完成身份驗證過程後，授權服務器會生成一個包含授權碼的響應，並將用戶重定向回指定的 Redirect URI。任何偏離原始 Redirect URI 的情況都會導致代碼或令牌洩露。

Redirect URIs 的精確字符串匹配首次在 OAuth 2.0 Security Best Current Practices 的第 4.1 節中介紹。這一過程確保 Redirect URI 必須與註冊在授權服務器上的 URI 完全匹配。註冊 Redirect URI 的任何偏差都會導致錯誤響應。

我們已經收到很多關於實現通配符匹配 Redirect URIs 的社區請求。雖然通配符匹配為開發者管理多個子域或路徑，特別是隨機子域的數量較大時帶來便利，但它也引入了安全風險，如開放重定向攻擊。有關遺漏 Redirect URI 驗證所帶來的危險的實際說明，請參考我們的 OAuth 安全簡報 博客文章。

根據 OAuth 2.1 的嚴格安全標準，Logto 使用 Redirect URIs 的精確字符串匹配。這一決定優先考慮到 OAuth 流程的安全性。我們鼓勵開發者將所有可能的 Redirect URIs 註冊至 Logto 的授權服務器，而不是使用通配符匹配。這樣可以確保 thorough URI 驗證，幫助減輕潛在的安全漏洞。

隱式流程被棄用#

OAuth 2.0 的隱式授權流程是為了支持 SPAs，當用戶驗證後，訪問令牌直接在 URL 片段中返回。這種方法很方便，因為它避免了額外的令牌交換步驟，允許客戶端直接接收令牌。

然而，這種方便也有其缺點。訪問令牌可能會通過瀏覽器歷史、引用標頭或其他方式暴露給未經授權的各方，特別是在訪問令牌長時間有效的情況下，使安全漏洞更容易發生。例如，如果授權請求被惡意方攔截，他們可以輕易從 URL 片段中提取訪問令牌並冒充用戶。

在 OAuth 2.0 Security Best Current Practices 中明確指出：

客戶端不應使用隱式授權（響應類型 "token"）或其他在授權響應中發放訪問令牌的響應類型。

因此，隱式流程已從 OAuth 2.1 規範中正式移除。

在 Logto 中，授權碼流程與 PKCE 是唯一支持的 SPAs 和移動應用的流程。授權碼流程通過交換授權碼提供了一種更安全的獲取訪問令牌的方式。

資源所有者密碼憑證（ROPC）授權被棄用#

資源所有者密碼憑證（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 中列出的最佳做法，以加強安全性和提高用戶體驗。