想像一下,您正在建立一個需要驗證使用者的網路或行動應用程式 - 可能是社群媒體平台、電子商務網站,甚至只是一個簡單的儀表板。在某些時候,您會問自己,「如何讓我的使用者安全登入?」
這就是身分驗證發揮作用的地方。但有如此多不同的方法可供選擇——例如會話管理、身份驗證令牌和日益流行的 JWT(JSON Web 令牌)——可能不太清楚哪一種方法適合您的應用程式。那你要如何決定呢?
如果您經常聽說智威湯遜,並且想知道它是否值得大肆宣傳,那麼您來對地方了。在這篇文章中,我們將詳細介紹 JWT 是什麼、它是如何運作的,以及它如何與 Django 中的其他常見身份驗證方法相比較。最後,您將清楚地了解何時使用 JWT 以及它與基於會話的身份驗證和身份驗證令牌等其他選項的比較。讓我們開始吧!
JWT(JSON Web 令牌)是一種緊湊的 URL 安全令牌格式,用於在各方之間安全地傳輸訊息。它通常用於客戶端請求存取資源的身份驗證過程,例如在 Web 或行動應用程式中。
JWT 由三個部分組成:
標頭:包含有關令牌的元數據,例如類型 (JWT) 和簽章演算法(例如 HS256)。
有效負載:包含特定於使用者的聲明,例如使用者的 ID、使用者名稱或角色。
簽名:透過使用金鑰對標頭和負載進行簽名,確保令牌未被竄改。
範例 JWT 可能如下所示:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImpvaG4iLCJleHAiOjE2MjEyMzY5MjZ9.GG7h8oV2C7Mcp93JK...
JWT 通常用於無狀態 身份驗證,這表示伺服器不儲存會話資料。相反,所有必要的資訊(聲明)都嵌入到代幣本身。
讓我們透過一個簡單的場景來分解 JWT 身份驗證的工作原理:
1。使用者登入
使用者透過登入表單提交電子郵件和密碼。伺服器驗證憑證,如果正確,伺服器會產生一個包含使用者資訊(如 ID、使用者名稱和角色)的 JWT。
2。令牌發送給客戶端
JWT 產生後,通常會在回應正文中傳回客戶端。客戶端儲存此令牌(在瀏覽器的 localStorage 或 sessionStorage 中,或安全地儲存在行動裝置上)。
3。使用者請求受保護的資源
每當客戶端需要存取受保護的路由時,它都會在請求的 Authorization 標頭中發送 JWT:
Authorization: Bearer <JWT_TOKEN>
然後,伺服器在授予對資源的存取權之前驗證令牌,確保其有效性和完整性。
4。令牌過期與刷新
由於 JWT 令牌有過期時間(例如 5 分鐘),一旦過期,用戶可以發送刷新令牌來獲取新的 JWT,而無需再次登入。
5。用戶登出
當使用者登出時,刷新令牌通常會被列入黑名單(在支援黑名單的設定中),確保使用者有效登出並且無法再刷新令牌。
JWT 是在 Django 應用程式中實現身份驗證的多種方法之一。讓我們看看 JWT 與其他常見方法(例如會話管理和身份驗證令牌。
的比較)會話管理:
在基於會話的身份驗證中,一旦使用者登錄,伺服器就會建立一個會話並將其儲存在資料庫或記憶體中。然後,會話 ID 透過 cookie 傳送到客戶端。客戶端儲存會話 ID 並在每次請求時發送它。然後,伺服器從儲存中檢索會話資料來識別使用者。
真實場景:
電子商務網站:想像您登入線上商店,將商品加入購物車,然後繼續結帳。此會話期間的每個操作(例如查看產品或更新購物車)都與儲存在伺服器上的會話 ID 相關聯。一旦您註銷,會話就會被銷毀。
JWT 與 Sessions:
- 儲存:
- 可擴充性:
- 資料傳輸:
- 安全:
- 過期與管理:
- 代幣大小:
- 用法:
驗證令牌:
在基於令牌的身份驗證中(如 Django 的內建令牌身份驗證),伺服器在使用者登入時產生一個唯一的令牌。此令牌儲存在伺服器上並發送到客戶端,客戶端將其包含在每個請求中。伺服器檢查資料庫中的令牌來驗證使用者。
真實場景:
API 存取: API 提供者(如 GitHub)在使用者登入後為使用者產生 API 令牌。每次與 GitHub API 互動時,該令牌都會在請求標頭中傳遞以驗證請求.
JWT 與驗證令牌:
- 令牌儲存
JWT(JSON Web 令牌):
無狀態:JWT 是獨立的,這意味著所有必要的資訊(聲明)都儲存在令牌本身內。伺服器不儲存令牌,這使其成為無狀態系統。
令牌通常儲存在客戶端(例如,在 localStorage、sessionStorage 或 cookies 中)並在授權標頭中隨每個請求一起傳送。
驗證令牌:
有狀態:在傳統的基於令牌的身份驗證中,令牌會產生並儲存在伺服器端(通常在資料庫中)。伺服器追蹤令牌,客戶端將其包含在每個請求中(通常在標頭中)。
- 代幣結構
智威湯遜:
自包含:JWT 令牌由三個部分組成:標頭、負載和簽名。有效負載包含使用者資訊(如 ID、電子郵件、角色)並經過簽名以確保完整性。
驗證令牌:
不透明令牌:身份驗證令牌通常是不透明字串,這表示它們不攜帶任何使用者資訊。它們充當對伺服器端會話或使用者資料的引用。
伺服器使用此令牌來尋找伺服器上儲存的會話或使用者資訊。
- 伺服器儲存與可擴充性
智威湯遜:
無伺服器儲存:由於 JWT 令牌是獨立的,因此伺服器不需要儲存會話或令牌資料。這使得它具有高度可擴展性,特別是在可能涉及多個伺服器的分散式系統或微服務架構中。
驗證令牌:
伺服器端儲存:身份驗證令牌儲存在伺服器上的資料庫或記憶體中,這意味著伺服器必須追蹤和驗證每個請求的令牌。這可能會降低可擴展性,因為伺服器需要為每個請求存取中央會話儲存。
- 安全考量
智威湯遜:
基於簽名:JWT 令牌使用 HS256 或 RS256 等演算法進行簽名,以確保令牌未被篡改。雖然這可以保護令牌的完整性,但它不會加密資料。除非加密,否則敏感資料不應包含在有效負載中。
客戶端風險:JWT 通常儲存在 localStorage 或 sessionStorage 中,這可能使它們容易受到 XSS(跨站腳本)攻擊。為了緩解這種情況,可以將它們儲存在僅限 HTTP 的 cookie 中。
驗證令牌:
伺服器端驗證:由於身份驗證令牌不包含使用者訊息,並且根據伺服器上的會話進行驗證,因此可以認為它們更安全,不會被篡改。然而,如果處理不當,它們很容易受到會話劫持或 CSRF(跨站請求偽造)攻擊。
- 過期與令牌壽命
智威湯遜:
短期存取權杖:JWT 通常具有較短的生命週期(例如 5-15 分鐘)。一旦過期,客戶端必須使用刷新令牌來取得新的存取令牌。這是 JWT 安全模型的關鍵部分。
刷新令牌:長期刷新令牌允許使用者保持登入狀態,而無需不斷重新輸入憑證,但它們也面臨自己的安全挑戰(例如,它們應該被安全地儲存和管理)。
驗證令牌:
預設沒有令牌過期:除非伺服器明確處理,否則驗證令牌預設不會過期。伺服器可以撤銷或使令牌過期,但這需要額外的邏輯和儲存來追蹤令牌的過期時間。
- 代幣大小
智威湯遜:
更大的令牌大小:由於 JWT 包含使用者資訊(聲明)和簽名,因此與不透明的身份驗證令牌相比,它們往往更大。這會稍微增加頻寬使用量,尤其是在請求頻繁的場景中。
驗證令牌:
較小的令牌大小:身份驗證令牌通常是不透明的字串,這意味著它們的大小要小得多。它們充當標識符並且不攜帶額外的數據,因此它們使用更少的頻寬。
- 使用場景範例
智威湯遜:
單頁應用程式 (SPA):JWT 與 SPA(如 React 或 Angular)配合良好,您需要無狀態驗證且不需要伺服器端會話管理。
微服務和 API:JWT 非常適合 API 和微服務架構,其中多個服務需要對使用者進行身份驗證,而無需跨伺服器共享會話狀態。
身份驗證令牌:
傳統 Web 應用程式:在伺服器渲染的 Web 應用程式中,通常使用身份驗證令牌(或會話),因為它們在伺服器端儲存和驗證,這使得它們非常適合易於維護會話的應用程式。
小型應用程式:身份驗證令牌非常適合用戶較少的應用程序,其中會話管理不會成為可擴展性問題。
- 無狀態與有狀態
智威湯遜:
無狀態:由於 JWT 不需要伺服器端存儲,因此它們使應用程式無狀態。這有利於跨多個伺服器水平擴展,因為伺服器之間不需要會話同步。
身份驗證令牌:
有狀態:身份驗證令牌需要伺服器端會話存儲,這表示伺服器會追蹤會話資料。這對於小型應用程式來說很好,但在擴展到多個伺服器時可能會出現問題,除非使用中央會話儲存(如 Redis)。
- 黑名單與撤銷
智威湯遜:
難以撤銷:由於 JWT 是無狀態的並且不儲存在伺服器上,因此一旦發布就很難撤銷它們,除非您使用令牌黑名單。這意味著如果令牌被洩露,它在過期之前仍然有效。
需要列入黑名單:為了處理令牌撤銷(例如,登出時),必須在伺服器上實作黑名單機制來追蹤無效的令牌。
驗證令牌:
易於撤銷:身份驗證令牌儲存在伺服器上,因此撤銷或使其失效非常簡單。
基本驗證:
在基本驗證中,用戶端會在每次請求時發送使用者的憑證(使用者名稱和密碼),通常以 base64 編碼。此方法常用於內部系統或簡單設定。
真實場景:
內部管理儀表板:一家小公司的內部管理儀表板要求使用者使用基本驗證登入。當使用者造訪頁面時,他們的憑證會在請求中發送。
讓我們考慮一個現實世界的範例:一個社群媒體平台,用戶可以在其中登入、與貼文互動以及跨多個裝置管理他們的個人資料。
在這樣的系統中:
選擇正確的身份驗證方法取決於您的應用程式的要求:
JWT 非常適合無狀態、可擴展的應用程式(例如 SPA、行動應用程式和微服務)。
基於會話的身份驗證非常適合傳統 Web 應用程式,其中可擴展性不是主要問題。
驗證令牌是一種簡單、安全的方法,用於小規模 API 驗證,其中伺服器端令牌儲存是可管理的。
每種方法都有其優點和缺點,但 JWT 因其處理現代分散式系統的能力而脫穎而出,其中可擴展性和靈活性是關鍵。
以上是身份驗證和授權 - 正確的方法!的詳細內容。更多資訊請關注PHP中文網其他相關文章!