JWT 與 Session 驗證比較
學習基於 Session 和 JWT 驗證的差異。探索權衡、優勢和使用案例,以為你的應用選擇合適的驗證方案。
學習基於 Session 和 JWT 驗證的差異。探索權衡、優勢和使用案例,以為你的應用選擇合適的驗證方案。
一般來說,使用應用程式的第一步是驗證,用戶需提供身份憑證以成功登錄。完成這步驟後,身份系統(即身份提供者、驗證伺服器等)即知曉用戶身份以及其能訪問的資源。
鑑於 HTTP 本質上無狀態,Session 中的每個請求都是獨立的,無法回憶先前的資訊。每次動作都要重新驗證用戶相當麻煩,並會損害用戶體驗。
讓我們來看看 基於 Session 的驗證 與 JWT (JSON Web Tokens) 驗證,這兩種維護驗證狀態的熱門方法。每種方法都有其獨特的優勢和權衡,而選擇取決於你的應用程式的具體需求。如果你正在這兩者之間做決定,本指南將為你提供幫助。
基於 Session 的驗證依賴於伺服器來維護用戶的驗證狀態記錄。通過創建和管理 Session,伺服器可以讓用戶保持登錄狀態,並繼續與應用程式互動,而無需每次請求都重新輸入憑證。
Session 創建
SessionID 會儲存在數據庫中並作為Cookie回傳到用戶的客戶端。Session 驗證
SessionID)。SessionID。可以即時使 Session 失效,這對於需要快速撤銷訪問的情況非常有用。
JSON Web Tokens (JWTs) 採用不同的方法,將所有相關的用戶信息直接嵌入到一個 JSON 對象的 Token 中。與基於 Session 的方法不同,JWTs 是無狀態的,意味著伺服器不管理驗證記錄。
JWT 包含三部分:標頭、有效載荷和簽名。

JWT 發行
基於 Session 的工作流程遵循類似的過程。然而,驗證後,用戶信息儲存在伺服器內的 Session 中,而 JWT 依賴於 Token 發送至客戶端進行儲存和後續使用。
Token 驗證
Authorization 標頭中(Bearer <token>)。基於 Session 的驗證需要伺服器查詢一個 Session 儲存器,這在依賴外部或集中式數據庫時可能會很慢。 相比之下,JWT 驗證是無狀態的,所有必要的信息儲存在客戶端的 Token 中,並使用簽名來確保安全性。這消除了 Session 管理的需要,尤其是在分佈式系統中,使其更快速和可擴展。
在客戶端,簽出通常意味著清除本地 Session 並從儲存中移除 Token(ID、訪問、刷新 Token)。然而,對於 JWT 驗證,這僅在本地簽出用戶,與授權伺服器的集中 Session 保持不變。因此,除非 Token 到期或手動終止,用戶可能仍能訪問同一 Session 下的其他應用程式。
撤銷 JWT (JSON 網路 Token)比基於 Session 的驗證更具挑戰性,因為 JWT 是無狀態的,除非實施特定策略,否則一旦發行就無法使其失效。常見的方法包括:
exp 聲明(例如,15 分鐘)給 JWT。一旦過期,用戶必須重新驗證。這將 Token 被洩露的風險降至最低,因為攻擊者只能在有限時間內使用它。為了保持流暢的用戶體驗,刷新 Token 可以用來將重新驗證的影響降到最低。JWT 不會實時更新
一旦 JWT 被簽署,無法撤銷或更新,只要簽名有效且未過期,就會被認作有效。
如果用戶的訪問權限改變(通常降低),用戶將繼續對資源有已移除的訪問權限,直到 JWT 到期。 同樣,如果 JWT 包含基於角色的授權信息,新的授權範圍將不會在舊 JWT 到期之前生效。 換句話說,JWT 不適用於實時撤銷,用戶可以設置適當的到期時間來緩解該問題。
多設備和撤銷困境
不可能在所有發行的 JWT 到期之前進行驗證以實現所有設備的用戶撤銷。 雖然理論上可以撤銷簽署密鑰來使 JWT 失效,但這也會使所有使用該密鑰的 JWT 失效,處理快取密鑰的過程讓這種方法對於簡單的用戶撤銷操作來說不切實際。
某些身份提供者可能已針對這些 JWT 問題提供現成的解決方案。想要了解更多信息,請查看 "增強 JWT 驗證體驗的最佳實踐。”
Session 和 JWT 是二種在無狀態 HTTP 世界中持續驗證和授權上下文的流行方法。 雖然這兩種方法都有其利弊,但它們提供了不同的好處和缺點。
Session 為每個請求的授權提供了更強的保證,可以更簡單地安全實施。但它們依賴於伺服器端數據庫驗證,這引入の的延遲,可能對高響應應用程式的用戶體驗造成負面影響。
另一方面,JWT 因更快的授權和與外部應用程式的互操作性而有利,但需要更多開發者的努力來解決安全性的複雜性。 例如,我們可以使用 webhooks 通知客戶端用戶的訪問被撤銷,這樣客戶端可以清除快取的 JWT 並迫使用戶重新驗證。
由於基於 Token 的驗證更適合擴展,其缺點仍可被管理,越來越多的現代應用程式正在採用它。
你的驗證方法應與應用程式的架構和具體需求相匹配。以下是一個快速指南幫助你做決定:
當你需要實時的 Session 控制,需集中管理或擴展性不是主要考慮時,基於 Session 的驗證效果最好。以下是它發揮突出作用的情況:
具有持續 Session 的 Web 應用程式
對於如網上購物網站這樣的平台,Session 對於跟踪用戶、購物車和偏好配置是必要的。
需要實時 Session 控制的應用程式
如銀行或金融服務等應用程式受益於伺服器控制的 Session 數據,保證強健的訪問管理和安全性。
單伺服器或小型系統
不需要大量擴展的內部工具或小型應用程式依靠簡單的 Session 管理以便於使用和可靠性。
JWT 教認更適合優先考慮擴展性、效率和分佈式系統的應用程式。 它特別適用於客戶端和伺服器間的無狀態交互。考慮以下場景使用基於 Token 的驗證:
單點登入 (SSO)
JWT 非常適用於單點登入,允許用戶一次驗證即能無縫訪問多個服務或應用,都是使用同一 Token。詳細解釋使用 OAuth 2.0 和 OIDC 保護雲端應用,在 訪問 Token 和 ID Token 上皆使用 JWT 格式。
行動應用程式
行動應用程式一般更偏好使用 JWT 驗證,因為 Token 可以安全地儲存在設備上,並隨著每次 API 請求發送。探索Android / iOS 中快速整合 JWT 驗證。
微服務架構
在微服務環境中,JWT 允許每個服務獨立驗證 Token 而不依賴中心 Session 儲存,保證擴展性和效率。
跨域驗證
JWT 在涉及多個域或子域的場景中表現出色(例如,api.example.com,dashboard.example.com,和 docs.example.com)。 與 cookies 不同,JWT 允許跨域驗證而無需額外依賴。
API 和 Web 服務
RESTful APIs 和 Web 服務通常使用 JWT 進行驗證,因為它們輕量、便攜,並消除伺服器端 Session 管理的必要性。了解更多機器對機器驗證場景,讓你的應用能夠直接與資源通信。
JWT 驗證是一個強大的工具,但它可能帶來影響用戶體驗的挑戰。Logto 提供了一個簡單和可靠的解決方案來克服這些困難,使其成為安全且高效的驗證的首選。
JWT 驗證的一個常見問題是確保正確的用戶登出體驗。 Logto 透過其現成的 SDK 簡化了這一過程。
這確保了你生態系統中的一致和安全的 Session 管理。 了解更多關於登出機制和如何實施登出。
使用 JWT 管理用戶權限的實時變更也可能較為棘手。由於 JWT 本質上是無狀態的,任何更新的權限或角色可能不會生效,直到 Token 到期。 Logto 提供策略來有效處理此問題:
這些解決方案有助於保持權限更新,確保更安全、更快速的系統。了解更多關於管理用戶權限的實時變更。