首頁 > 後端開發 > Python教學 > 身份驗證和授權 - 正確的方法!

身份驗證和授權 - 正確的方法!

Mary-Kate Olsen
發布: 2024-10-09 06:14:29
原創
787 人瀏覽過

Authentication and Authorization - the correct way!

想像一下,您正在建立一個需要驗證使用者的網路或行動應用程式 - 可能是社群媒體平台、電子商務網站,甚至只是一個簡單的儀表板。在某些時候,您會問自己,「如何讓我的使用者安全登入?」

這就是身分驗證發揮作用的地方。但有如此多不同的方法可供選擇——例如會話管理、身份驗證令牌和日益流行的 JWT(JSON Web 令牌)——可能不太清楚哪一種方法適合您的應用程式。那你要如何決定呢?

如果您經常聽說智威湯遜,並且想知道它是否值得大肆宣傳,那麼您來對地方了。在這篇文章中,我們將詳細介紹 JWT 是什麼、它是如何運作的,以及它如何與 Django 中的其他常見身份驗證方法相比較。最後,您將清楚地了解何時使用 JWT 以及它與基於會話的身份驗證和身份驗證令牌等其他選項的比較。讓我們開始吧!

什麼是 JWT(JSON Web 令牌)?

JWT(JSON Web 令牌)是一種緊湊的 URL 安全令牌格式,用於在各方之間安全地傳輸訊息。它通常用於客戶端請求存取資源的身份驗證過程,例如在 Web 或行動應用程式中。

JWT 由三個部分組成:

標頭:包含有關令牌的元數據,例如類型 (JWT) 和簽章演算法(例如 HS256)。

有效負載:包含特定於使用者的聲明,例如使用者的 ID、使用者名稱或角色。

簽名:透過使用金鑰對標頭和負載進行簽名,確保令牌未被竄改。

範例 JWT 可能如下所示:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImpvaG4iLCJleHAiOjE2MjEyMzY5MjZ9.GG7h8oV2C7Mcp93JK...
登入後複製

JWT 通常用於無狀態 身份驗證,這表示伺服器不儲存會話資料。相反,所有必要的資訊(聲明)都嵌入到代幣本身。

JWT 的工作原理:逐步過程

讓我們透過一個簡單的場景來分解 JWT 身份驗證的工作原理:

1。使用者登入
使用者透過登入表單提交電子郵件和密碼。伺服器驗證憑證,如果正確,伺服器會產生一個包含使用者資訊(如 ID、使用者名稱和角色)的 JWT。

2。令牌發送給客戶端
JWT 產生後,通常會在回應正文中傳回客戶端。客戶端儲存此令牌(在瀏覽器的 localStorage 或 sessionStorage 中,或安全地儲存在行動裝置上)。

3。使用者請求受保護的資源
每當客戶端需要存取受保護的路由時,它都會在請求的 Authorization 標頭中發送 JWT:

Authorization: Bearer <JWT_TOKEN>

登入後複製

然後,伺服器在授予對資源的存取權之前驗證令牌,確保其有效性和完整性。

4。令牌過期與刷新
由於 JWT 令牌有過期時間(例如 5 分鐘),一旦過期,用戶可以發送刷新令牌來獲取新的 JWT,而無需再次登入。

5。用戶登出
當使用者登出時,刷新令牌通常會被列入黑名單(在支援黑名單的設定中),確保使用者有效登出並且無法再刷新令牌。

JWT 與 Django 中的傳統身份驗證方法

JWT 是在 Django 應用程式中實現身份驗證的多種方法之一。讓我們看看 JWT 與其他​​常見方法(例如會話管理身份驗證令牌

的比較)

1. JWT 身份驗證與會話管理

會話管理:
在基於會話的身份驗證中,一旦使用者登錄,伺服器就會建立一個會話並將其儲存在資料庫或記憶體中。然後,會話 ID 透過 cookie 傳送到客戶端。客戶端儲存會話 ID 並在每次請求時發送它。然後,伺服器從儲存中檢索會話資料來識別使用者。

真實場景:

電子商務網站:想像您登入線上商店,將商品加入購物車,然後繼續結帳。此會話期間的每個操作(例如查看產品或更新購物車)都與儲存在伺服器上的會話 ID 相關聯。一旦您註銷,會話就會被銷毀。

JWT 與 Sessions:

- 儲存:

  • JWT:無狀態,無伺服器端儲存。所有資料都包含在令牌本身內。
  • Sessions:有狀態的,伺服器儲存會話資料(通常在資料庫或記憶體中),並向客戶端發送會話ID。

- 可擴充性:

  • JWT:高度可擴展;無需儲存使用者會話信息,輕鬆跨伺服器水平擴展。
  • 會話:可擴展性較差;需要跨伺服器管理和共用會話資料(例如,使用集中式會話儲存)。

- 資料傳輸:

  • JWT:令牌包含所有使用者資料(聲明)並隨每個請求一起發送。如果包含太多數據,它可能會變得很大。
  • 會話:僅傳送會話 ID,並從伺服器檢索使用者資料。

- 安全:

  • JWT:如果令牌未安全地儲存在用戶端(例如本機儲存),則容易受到攻擊。安全地處理令牌過期和刷新非常重要。
  • 會話:通常使用 cookie 來儲存會話 ID,如果使用 HTTP-only 和 Secure 標誌,會話 ID 會更安全。然而,它可能容易受到 CSRF 攻擊。

- 過期與管理:

  • JWT:令牌有過期時間。如果使用刷新令牌,則無需重新驗證即可更新存取令牌。
  • 會話:會話也有超時期限,但只要使用者與應用程式交互,就可以輕鬆延長超時時間。

- 代幣大小:

  • JWT:由於所有資料都包含在令牌中,JWT 可以更大,特別是如果它們攜帶大量使用者資訊或元資料。
  • 會話:每個請求僅傳送會話 ID,因此資料傳輸量最少。

- 用法:

  • JWT:現代無狀態 API、單頁應用程式 (SPA) 和行動應用程式中的首選。
  • 會話:常見於伺服器管理使用者狀態的傳統 Web 應用程式。

2. JWT 身份驗證與身份驗證令牌

驗證令牌:
在基於令牌的身份驗證中(如 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 是無狀態的並且不儲存在伺服器上,因此一旦發布就很難撤銷它們,除非您使用令牌黑名單。這意味著如果令牌被洩露,它在過期之前仍然有效。

需要列入黑名單:為了處理令牌撤銷(例如,登出時),必須在伺服器上實作黑名單機制來追蹤無效的令牌。

驗證令牌:

易於撤銷:身份驗證令牌儲存在伺服器上,因此撤銷或使其失效非常簡單。

3. JWT 身份驗證與基本身份驗證

基本驗證:
在基本驗證中,用戶端會在每次請求時發送使用者的憑證(使用者名稱和密碼),通常以 base64 編碼。此方法常用於內部系統或簡單設定。

真實場景:

內部管理儀表板:一家小公司的內部管理儀表板要求使用者使用基本驗證登入。當使用者造訪頁面時,他們的憑證會在請求中發送。

現實世界用例:何時使用 JWT?

讓我們考慮一個現實世界的範例:一個社群媒體平台,用戶可以在其中登入、與貼文互動以及跨多個裝置管理他們的個人資料。

在這樣的系統中:

  1. JWT 運作得很好,因為它是無狀態的,這意味著伺服器不需要儲存使用者會話。
  2. 客戶端可以在本機儲存令牌,這允許使用者在不同的選項卡和裝置上保持登入狀態。
  3. 由於應用程式可以跨多個伺服器水平擴展(例如,一台伺服器用於處理帖子,另一台伺服器用於設定檔),因此使用 JWT 可以更輕鬆地擴展,而無需中央會話儲存。
  4. 使用者還可以定期刷新其令牌以保持存取權限,而無需再次登入。

結論:選擇哪一種身份驗證方法?

選擇正確的身份驗證方法取決於您的應用程式的要求:

JWT 非常適合無狀態、可擴展的應用程式(例如 SPA、行動應用程式和微服務)。
基於會話的身份驗證非常適合傳統 Web 應用程式,其中可擴展性不是主要問題。
驗證令牌是一種簡單、安全的方法,用於小規模 API 驗證,其中伺服器端令牌儲存是可管理的。

每種方法都有其優點和缺點,但 JWT 因其處理現代分散式系統的能力而脫穎而出,其中可擴展性和靈活性是關鍵。

以上是身份驗證和授權 - 正確的方法!的詳細內容。更多資訊請關注PHP中文網其他相關文章!

來源:dev.to
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
作者最新文章
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板