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

授權碼流程 和 隱式流程 是 OAuth 2.0 中最常用的兩種授權類型，使 web 應用程式能夠實現安全高效的用戶授權。兩種流程都實現了一個授權過程，允許用戶授予應用程式訪問權限而不直接暴露其憑證。隱式流程最初是為了解決瀏覽器限制而開發的，但隨著現代 web 技術的出現，許多開發者更傾向於使用授權碼流程，因為它具有更強的安全功能。

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

什麼是 OAuth 2.0？#

在我們深入了解這兩種授權類型之前，讓我們首先了解 OAuth 2.0 是什麼，以及為什麼它對現代 web 應用程式至關重要。

當人們談論 OAuth 時，我們通常指的是 OAuth 2.0，被稱為 "開放授權"，是一個被建立的協議，使網站或應用程式能夠代表用戶使用其他 web 服務的資源。它在 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 的授權碼流程可以為你和你的用戶提供更好的安全性。我們理解進行身份系統遷移和管理可能是繁瑣且昂貴的，但增強的安全性和合規性的好處完全值得這樣的努力。