隱式流程 vs. 授權碼流程:為什麼隱式流程已死?
為什麼在 OAuth 2.0 中有「授權碼流程」時我們已經有了「隱式流程」呢?讓我們深入了解這兩種授權類型的細節,並找出為什麼應避免使用隱式流程。
為什麼在 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 中最常見的授權類型有:
隱式流程是一種簡化的 OAuth 2.0 流程,其中訪問令牌直接在重定向 URI 中返回給客戶端,而不需要額外的步驟來交換授權碼以獲得令牌。它最初是為不能從瀏覽器中向令牌端點發起服務器端請求的 Web 應用程序設計的。
隱式流程具有以下安全漏洞:
由於這些安全問題,隱式流程已不再推薦用於現代 Web 應用程序。取而代之的是帶有 PKCE(代碼交換證明密鑰)的授權碼流程,這是安全地用戶授權的首選。
另一方面,授權碼流程是一種更安全的 OAuth 2.0 流程,將授權過程分為兩個步驟:客戶端應用程序首先從授權伺服器獲得授權碼,然後交換該碼以獲取訪問令牌。這種流程最初設計用於能夠安全存儲客戶端憑據並管理訪問令牌的服務器端 Web 應用程序。隨著 PKCE 擴展的引入,授權碼流程現在也可以用於基於瀏覽器的應用程序。
了解更多關於 PKCE 流程的信息。
| 方面 | 授權碼流程 | 隱式流程 |
|---|---|---|
| 令牌交付 | 通過安全請求將訪問令牌交付給客戶端 | 訪問令牌直接在 URL 片段中交付給客戶端 |
| 安全級別 | 高(令牌未在瀏覽器中暴露) | 低(令牌在瀏覽器中暴露) |
| 使用情境 | 服務器端 Web 應用程序和基於瀏覽器的應用程序(帶 PKCE) | 僅限於基於瀏覽器的應用程序 |
| 現代使用 | 建議作為所有類型應用程序的首選 | 不建議,應避免使用 |
答案是肯定的:
授權碼流程引入了額外的步驟,以交換授權碼來獲取訪問令牌,這顯著降低了令牌暴露的風險。
如果你目前在業務中使用隱式流程,切換到帶有 PKCE 的授權碼流程可以為你和你的用戶提供更好的安全性。我們理解遷移和管理身份系統可能會很繁瑣和昂貴,但增強的安全性和合規性帶來的好處非常值得這個努力。