JWT 與會話驗證

一般來說，使用應用程式的第一步是驗證，其中終端使用者提供其身份憑據以成功登入。在這一步驟之後，身份系統（即身份提供者、驗證伺服器等）知道使用者是誰以及他們可以訪問哪些資源。

由於 HTTP 本質上是無狀態的，因此會話中的每個請求都是獨立的且不會回憶以前的資訊。每次操作重新驗證使用者既繁瑣又損害用戶體驗。

讓我們來看看基於會話的驗證和JWT（JSON Web Tokens）驗證，這是維持驗證狀態的兩種流行方法。每種方法都有獨特的優勢和權衡，選擇其中之一取決於你的應用程式的具體需求。如果你正在兩者之間做決定，本指南將為你提供幫助。

什麼是基於會話的驗證？#

基於會話的驗證依賴於伺服器來保持使用者驗證狀態的記錄。通過創建和管理會話，伺服器允許使用者保持登錄狀態並繼續與應用程式互動，而不必在每次請求時重新輸入憑據。

基於會話的驗證如何運作？#

會話創建

1. 使用者驗證並提供一些憑據（例如，電子郵件和密碼）。
2. 如果憑據有效，伺服器會創建一個持久性記錄來表示該會話。會話包含信息如隨機字符串、使用者標識符、會話開始時間、會話到期時間等。
3. SessionID 存儲在數據庫中，並以cookie的形式返回給使用者的客戶端。

會話驗證

1. 該過程可以由使用者手動觸發（例如，點擊選項卡，刷新頁面）或由客戶端自動觸發（例如，在頁面加載初期或通過帶有 SessionID 的 API 調用）。
2. 每次後續調用時，從客戶端發送包含會話 cookie 的 HTTP 請求到伺服器。
3. 伺服器通過諮詢存儲在伺服器上的會話數據來驗證 SessionID。
4. 如果有效，伺服器處理請求並授權使用者。

如何撤銷會話？#

可以實時使會話失效，在需要快速撤銷訪問權限的情況下非常便利。

• 用戶手動登出: 伺服器刪除會話記錄，從而實際上將使用者登出。
• 管理員強制使用者登出: 管理員或系統可以通過從數據庫中刪除特定會話來終止它。例如，在安全漏洞期間。
• 會話過期: 會話可以在設置的不活動持續時間或一定的時間限制後自動過期。

基於會話認證的優勢#

• 簡單且可靠: 會話記錄提供清晰、集中的來源，允許高度信任並使授權決策更加可靠。
• 實時撤銷: 通過刪除或使會話記錄無效，可以快速撤銷用戶的訪問權限。

基於會話認證的缺點#

• 分佈式系統的延遲: 在多台伺服器之間維護會話數據總是需要同步會話存儲。這會引入額外的延遲，因為伺服器每次請求都必須檢查會話存儲。
• 高資源消耗: 每段會話佔用伺服器資源，當用戶基數增加時會影響性能。
• 安全風險: 會話劫持（通過竊取會話 cookie）可能允許未經授權的訪問用戶帳戶。
• 對 API 限制: 基於會話的認證對移動應用不太理想。它在伺服器上存儲會話數據，大量用戶會增加負載和複雜性。此外，它使用 cookie，這在移動設備上更難處理。

什麼是 JWT 驗證？#

JSON Web Tokens (JWTs) 採用不同的方法，將所有相關的用戶信息直接嵌入到令牌中，使用 JSON 對象。與基於會話的方法不同，JWTs 是無狀態的，意味著伺服器不會管理認證記錄。

JWT 認證是如何工作的？#

JWT 由三個部分組成：頭部、負載和簽名。

• 頭部包含簽名算法（例如，HS256）和令牌的類型（JWT）。
• 負載包含核心聲明，例如用戶身份、用戶角色和到期時間。
• 簽名使用密鑰對頭部和負載進行簽名，允許驗證簽名是否被篡改。

JWT 發行

1. 客戶端向認證伺服器發送用戶憑據（一個通用的身份提供者對於管理跨多個域的訪問特別有益）。
2. 驗證成功後，伺服器生成一個包含頭部、負載和簽名的 JWT。
3. 認證伺服器向客戶端發送發行的令牌。客戶端存儲 JWT（例如，在 cookies、localStorage 或 sessionStorage）。

基於會話的工作流遵循類似的過程。然而，驗證後，用戶信息存儲在伺服器上的會話中，而 JWTs 則依賴於發送到客戶端的令牌進行存儲和後續使用。

令牌驗證

1. 對於後續的 API 請求，客戶端在 Authorization 標頭中發送 JWT（Bearer <token>）。
2. 伺服器使用密鑰驗證 JWT 的簽名並檢查其聲明（例如，到期時間、簽發者）。
3. 如果令牌有效，伺服器向客戶端授予訪問所請求資源的權限。

基於會話的驗證要求伺服器查詢會話存儲，尤其是如果依賴外部或集中數據庫時可能會很慢。相比之下，JWT 認證是無狀態的，所有必要的信息都存儲在客戶端的令牌中，並利用簽名來確保安全。這消除了會話管理的需求，特別是在分布式系統中使其更快、更具可伸縮性。

如何撤銷 JWT？#

在客戶端上簽出通常意味著清除本地會話並從存儲中刪除令牌（ ID、訪問、刷新令牌）。然而，對於 JWT 認證，這只會在本地簽出使用者，離開授權伺服器上的集中會話處於不變狀態。結果是直到令牌過期或被手動終止，使用者可能仍然可以訪問同一會話下的其他應用程式。

撤銷 JWT（JSON Web Token）比基於會話的驗證更具挑戰性，因為 JWTs 是無狀態的，因此一旦發行就不能被使無效，除非實現了特定策略。常見的方法包括：

• 短到期時間: 為 JWT 設置一個較短的 exp 聲明（例如，15 分鐘）。一旦過期，用戶必須重新驗證。如果令牌遭到破壞，攻擊者只能在有限的時間內使用它，從而將風險降到最低。為了保持無縫用戶體驗，可以使用刷新令牌來最大限度地減少重新驗證的不便。
• 令牌黑名單: 對於關鍵情況（例如，用戶註銷、密碼更改），維護一個被撤銷令牌的黑名單。伺服器檢查傳入的令牌是否與此黑名單匹配，並拒絕任何匹配的令牌。雖然有效，但這種方法需要跟踪被撤銷的令牌，這與 JWTs 的無狀態性相悖，如果黑名單增長過大，可能會變得低效。
• 撤銷端點: 在授權伺服器上引入一個撤銷端點，可以使令牌（例如，刷新令牌）無效。一旦一個刷新令牌被撤銷，任何由其簽發的訪問令牌都將無法被刷新。此方法在OAuth2工作流程中效果良好。

JWT 認證的優勢#

• 快速且更具資訊性: JWTs 的自包含性質使得客戶端驗證更快、更高效，無需伺服器交互。它們還可以包括定制聲明（例如，用戶角色或其他相關數據）在令牌中，允許伺服器在不查詢數據庫的情況下確定角色。
• 增強安全性: JWTs 使用簽名和加密技術，使攻擊更加困難。
• 跨域支持: JWTs 非常適合單點登錄 (SSO)和跨域驗證。它們允許用戶使用相同的令牌跨多個域或服務進行身份驗證。
• 適合移動端: JWTs 非常適合需要無狀態驗證的移動應用程式。令牌可以存儲在客戶端中，並隨每次請求發送，提高效率和易用性。

JWT 認證的缺點#

• JWT 無法即時更新

  一旦 JWT 被簽名，就無法撤銷或更新，而且只要簽名有效並且未過期，它就會被視為有效。

  如果用戶的訪問權限更改（通常會降權），在 JWT 過期之前，用戶仍將具有對資源的已移除訪問權限。同樣，如果 JWT 包含基於角色的授權信息，新授權範圍在舊 JWT 過期之前不會生效。這意味著，JWTs 不適合即時撤銷，用戶可以設置適當的到期時間來緩解這一問題。

• 多設備和撤銷困境

  在 JWT 過期之前，使所有發行的 JWT 無效以實施用戶撤銷所有設備是不可能的。雖然理論上可以撤銷簽名密鑰以使 JWT 無效，但這也會使使用該密鑰的所有 JWTs 無效，而處理緩存密鑰的過程會使這一方法對簡單的用戶撤銷操作而言不切實際。

一些身份提供者可能對這些 JWT 問題有預建解決方案。要了解更多資訊，請參閱「改進 JWT 驗證體驗的最佳實踐」。

JWT 和會話有什麼不同？#

會話和 JWTs 是兩種在無狀態 HTTP 世界中持續驗證和授權上下文的流行方法。雖然這兩種方法各有優劣勢，但它們提供不同的好處和缺點。

會話為個別請求授權提供更強的保障，並且更容易安全地實施。然而，由於依賴伺服器端數據庫驗證，會引入延遲開銷，這可能會對需要快速響應的應用程式的用戶體驗產生負面影響。

另一方面，JWTs 有利於更快速的授權和與外部應用程式的互操作性，但需要開發者付出更多努力來解決安全複雜性問題。例如，我們可以使用 Webhook 當用戶的訪問被撤銷時通知客戶端，從而讓客戶端清除緩存的 JWT 並強制使用者重新驗證。

由於基於令牌的驗證更適合擴展，且其缺點仍可控，越來越多的現代應用程式正在採用它。

會話與 JWT：選擇正確的方法#

你的驗證方法應與你的應用程式架構和具體需求相匹配。這裡有一個快速指南來幫助你決定：

何時使用基於會話的驗證#

當你需要實時會話控制、需要集中管理或擴展性不是主要考慮因素時，基於會話的驗證效果最佳。以下是它發揮作用的地方：

• 具有持久會話的 Web 應用程式

  對於像在線購物網站這樣的平台，會話對於跟踪用户、購物車和訪問期間的偏好是必需的。

• 需要實時會話控制的應用程式

  銀行或金融服務等應用程式受益於伺服器控制的會話數據，確保強大訪問管理和安全性。

• 單伺服器或小規模系統

  沒有重大擴展需求的內部工具或小規模應用程式依賴於簡單的會話管理以提高易用性和可靠性。

何時使用 JWT 驗證#

JWT 驗證更適合優先考慮擴展性、效率的應用程式和分布式系統。它特別適用於客戶端和伺服器之間的無狀態交互。考慮基於令牌的驗證以滿足以下需求：

• 單點登錄（SSO）

  JWTs 非常適合 單點登錄，允許用戶驗證一次並使用相同令牌無縫訪問多個服務或應用程式。分享關於使用 OAuth 2.0 和 OIDC 安全雲應用的詳細說明，使用 JWT 格式作為訪問令牌和身份令牌。

• 移動應用程式

  移動應用通常更偏愛 JWTs 進行驗證，因為令牌可以安全存儲在設備上並隨每次 API 請求發送。探索 Android / iOS 認證的快速集成 JWT 的方法。

• 微服務架構

  在微服務環境中，JWTs 允許每個服務獨立驗證令牌，而無需依賴中央會話存儲，確保可擴展性和效率。

• 跨域驗證

  JWTs 在涉及多個域或子域（例如 api.example.com、dashboard.example.com 和 docs.example.com）的場景中表現出色。與 cookie 不同，JWTs 允許在沒有額外依賴的情況下進行跨域驗證。

• API 和 Web 服務

  RESTful APIs和 Web 服務通常使用 JWTs 進行驗證，因為它們輕量且易於攜帶，消除了伺服器端會話管理的需求。了解更多關於機器對機器的驗證的場景，你的應用程式需要直接與資源進行通信。

改善 JWT 認證體驗的最佳實踐#

JWT 認證是個很好的工具，但可能會帶來影響用戶體驗的挑戰。Logto 提供了一個簡單且可靠的解決方案來克服這些障礙，使其成為安全且高效認證的首選。

處理 JWT 的用戶退出問題#

JWT 認證的一個常見問題是確保適當的用戶退出體驗。Logto 提供其現成的 SDK 簡化了此過程。

• 通過清除客戶端上的令牌和本地主機會話並將用戶重定向到 Logto 的 會話結束端點，你可以輕鬆地終止客戶端應用程式和伺服器上的會話。
• 另外，Logto 支持 後通道註銷，允許認證伺服器在用戶登出時通知共享相同會話的所有客戶端應用程式。

這確保了在你的生態系統中一致且安全的會話管理。 了解更多關於處理登出。

處理用戶權限變更#

管理使用 JWT 的用戶權限的實時更改也可能棘手。由於 JWTs 本質上是無狀態的，任何更新的權限或角色在令牌過期之前可能無法生效。Logto 提供策略以有效應對此問題：

• 對於減少用戶的權限: 使用短的訪問令牌到期時間或通過 API 調用動態驗證權限。
• 對於給用戶增加新權限: 更新認證伺服器以包括新的權限範圍並重新獲得用戶的同意以應用這些變更。

這些解決方案有助於保持權限的更新，確保更安全、更響應迅速的系統。了解更多關於處理權限變更。

Logto 是一個可擴展的身份訪問管理基礎設施，提供一套完整的身份解決方案，既有雲服務也有開源版本。