隱式流程 vs. 授權碼流程：為什麼隱式流程已死？

授權碼流程和隱式流程是 OAuth 2.0 中最常用的兩種授權類型，能夠為網絡應用程序提供安全且高效的用戶授權。兩者都實施了一個授權過程，允許用戶授權應用程序訪問而不直接暴露其憑據。隱式流程最初是為了解決瀏覽器的限制而開發的，但隨著現代網絡技術的進步，授權碼流程因其增強的安全功能成為許多開發者的首選。

在本文中，我們將探討這兩種授權類型之間的區別並解釋為什麼應避免使用隱式流程而選擇授權碼流程。

什麼是 OAuth 2.0？#

在我們進入這兩種授權類型的詳細內容之前，首先了解一下什麼是 OAuth 2.0 以及它對於現代網絡應用程序的重要性。

當人們談論 OAuth 時，我們通常指的是 OAuth 2.0，這是一個被稱為「開放授權」的完善協議，使網站或應用程序能夠代表用戶利用來自其他網絡服務的資源。它在 2012 年取代了 OAuth 1.0，並自此成為數字授權的廣泛接受標準。OAuth 2.0 旨在提供受控訪問，使客戶端應用程序能夠特定地授權與代表用戶的資源進行交互，且不揭示用戶的登錄詳細信息。

儘管主要用於 Web 環境，但 OAuth 2.0 的框架也延伸到各種客戶端形式，包括基於瀏覽器的應用程序、服務器端 Web 應用程序、本地或移動應用程序，甚至互聯設備，詳細說明了在這些平台中管理委派訪問的方法。它引入了「授權類型」的概念，來定義客戶端應用程序、用戶和授權伺服器之間的授權過程。這些授權類型用於確定客戶端應用程序如何獲取訪問用戶資源的訪問令牌。在 OAuth 2.0 中最常見的授權類型有：

• 授權碼：適用於所有類型的應用程序，特別是服務器端 Web 應用程序，客戶端應用程序可以交換授權碼以獲取訪問令牌並安全地管理令牌。
• 隱式：一種簡化的流程，設計用於基於瀏覽器的應用程序，沒有安全的伺服器組件。它旨在快速將令牌交付給客戶端應用程序。但由於安全問題，它現在已大多已棄用。
• 資源所有者密碼憑據：此類型允許客戶端應用程序直接透過提交用戶憑據（用戶名和密碼）請求和獲得訪問令牌。由於客戶端應用程序有直接訪問用戶憑據的渠道，這種授權類型也被認為是已棄用的，應在所有情況下避免使用。
• 客戶端憑據：用於機器對機器通信，其中應用程序本身是客戶端。它涉及應用程序向授權伺服器進行身份驗證，並請求訪問令牌以訪問自身或其他服務的資源。

什麼是隱式流程？#

隱式流程是一種簡化的 OAuth 2.0 流程，其中訪問令牌直接在重定向 URI 中返回給客戶端，而不需要額外的步驟來交換授權碼以獲得令牌。它最初是為不能從瀏覽器中向令牌端點發起服務器端請求的 Web 應用程序設計的。

隱式流程如何工作？#

1. 用戶在客戶端應用程序上點擊按鈕或鏈接以啟動身份驗證過程。
2. 客戶端應用程序將用戶重定向到授權伺服器進行身份驗證，包含所需的訪問範圍。
3. 授權伺服器提示用戶登入並授權客戶端應用程序。
4. 一旦身份驗證和授權成功，授權伺服器將用戶的瀏覽器重定向回客戶端指定的重定向 URI，訪問令牌包含在 URL 片段中。
5. 客戶端應用程序從 URL 片段中提取訪問令牌，並使用該令牌訪問資源伺服器上的用戶資源。

隱式流程的安全風險#

隱式流程具有以下安全漏洞：

• 令牌暴露：訪問令牌直接在 URL 片段中返回給客戶端，容易被惡意方攔截。這使訪問令牌容易被竊取和濫用。
• CSRF 攻擊：隱式流程易受跨站點請求偽造 (CSRF) 攻擊，惡意網站可能誘騙用戶授權未經授權的訪問。

由於這些安全問題，隱式流程已不再推薦用於現代 Web 應用程序。取而代之的是帶有 PKCE（代碼交換證明密鑰）的授權碼流程，這是安全地用戶授權的首選。

什麼是授權碼流程？#

另一方面，授權碼流程是一種更安全的 OAuth 2.0 流程，將授權過程分為兩個步驟：客戶端應用程序首先從授權伺服器獲得授權碼，然後交換該碼以獲取訪問令牌。這種流程最初設計用於能夠安全存儲客戶端憑據並管理訪問令牌的服務器端 Web 應用程序。隨著 PKCE 擴展的引入，授權碼流程現在也可以用於基於瀏覽器的應用程序。

授權碼流程如何適用於具有服務器端組件的私有客戶端？#

1. 用戶在客戶端應用程序上點擊按鈕或鏈接以啟動身份驗證過程。
2. 客戶端應用程序將用戶重定向到授權伺服器進行身份驗證，帶有所需的訪問範圍。
3. 授權伺服器提示用戶登入並授權客戶端應用程序。
4. 身份驗證和授權成功後，授權伺服器將授權碼返回給客戶端。
5. 客戶端應用程序使用其客戶端憑據通過服務器到服務器的請求安全地交換授權碼以獲取訪問令牌。
6. 授權伺服器驗證授權碼和客戶端憑據，並將訪問令牌返回給客戶端。
7. 客戶端應用程序使用訪問令牌訪問資源伺服器上的用戶資源。

授權碼流程如何適用於帶有 PKCE 的公共客戶端？#

1. 用戶在客戶端應用程序上點擊按鈕或鏈接以啟動身份驗證過程。
2. 客戶端應用程序生成代碼驗證碼和代碼挑戰。
3. 客戶端應用程序將用戶重定向到授權伺服器以進行身份驗證，並帶代碼挑戰。
4. 授權伺服器存儲代碼挑戰以供稍後驗證。
5. 用戶驗證並授權客戶端應用程序訪問。
6. 授權伺服器將授權碼返回給客戶端。
7. 客戶端應用程序使用代碼驗證碼通過服務器到服務器的請求交換授權碼以獲取訪問令牌。
8. 授權伺服器檢驗授權碼和代碼驗證碼與存儲的代碼挑戰的匹配情況。
9. 授權伺服器向客戶端返回訪問令牌。
10. 客戶端應用程序使用訪問令牌訪問資源伺服器上的用戶資源。

了解更多關於 PKCE 流程的信息。

隱式流程 vs. 授權碼流程#

授權碼流程能否消除隱式流程的安全問題？#

答案是肯定的：

授權碼流程引入了額外的步驟，以交換授權碼來獲取訪問令牌，這顯著降低了令牌暴露的風險。

• 對於具有安全服務器端組件的私有客戶端，客戶端應用程序可以使用其客戶端憑據來安全交換授權碼以獲取訪問令牌。
• 對於沒有安全服務器端組件的公共客戶端，可以使用 PKCE 擴展來保護授權碼交換過程。

如果你目前在業務中使用隱式流程，切換到帶有 PKCE 的授權碼流程可以為你和你的用戶提供更好的安全性。我們理解遷移和管理身份系統可能會很繁瑣和昂貴，但增強的安全性和合規性帶來的好處非常值得這個努力。