身份驗證：JWT使用與會話

Question

JWT在身份驗證等情況下使用會話的優點是什麼？

它是作爲獨立的方法使用還是用於會話？

Answer 1

智威湯遜對每個說法都使用「會話」沒有好處。智威湯遜提供了一種在客戶端維護會話狀態的方法，而不是在服務器上進行。

問這是「什麼是使用JWTs在使用服務器端的會話的好處」

使用服務器端的會話，你將不得不會話標識符存儲在數據庫中，當人們往往意味着，否則將其保存在內存中並確保客戶端始終訪問同一臺服務器。這兩個都有缺點。在數據庫（或其他集中存儲）的情況下，這成爲一個瓶頸和一個維護的事情 - 本質上是一個額外的查詢要完成每個請求。

隨着內存解決方案，你限制你的水平縮放和會議將通過網絡問題（客戶端WiFi和移動數據，服務器重啓等之間的漫遊）

移動會話到客戶端意味着受影響您刪除了服務器端會話的依賴關係，但它強加了自己的一套挑戰。
- 安全地存儲令牌
- 安全地傳輸它
- 智威湯遜會話有時很難失效。
- 信任客戶的主張。

這些問題由JWT和其他客戶端會話機制共享。

智威湯遜特別強調了其中的最後一項。它可能有助於瞭解什麼是JWT：

這是一些信息。對於用戶會話，您可以包含用戶名和令牌到期的時間。但可以想象的是任何事情，甚至會話ID或用戶的整個配置文件。 （請不要這樣做） 它有一個安全的簽名，可以防止惡意方生成假令牌（您需要訪問服務器的私鑰來簽名，並且可以驗證它們在簽名後沒有被修改） 你發送它們的每一個請求，就像一個cookie或Authorization標題將被髮送。實際上，它們通常在HTTP Authorization標題中發送，但使用cookie也不錯。

令牌已簽名，因此服務器可以驗證其來源。我們將假設服務器相信自己的安全簽名能力（您應該使用標準庫：不要試圖自己動手，並且正確保護服務器）

關於安全傳輸令牌的問題，答案通常通過一個加密的通道發送，通常是httpS。

關於安全地將令牌存儲在客戶端中，您需要確保壞人無法訪問它。這（大部分）意味着阻止壞Web站點的JS讀取令牌以將其發回給它們。這可以通過使用相同的策略來減輕其他類型的XSS攻擊。

如果您有必要使JWT失效，那麼可以實現這些目標。只爲那些要求「終止其他會話」的用戶存儲每用戶時代是一種非常有效的方法，可能會足夠好。如果應用程序需要每會話失效，那麼會話ID可以以相同的方式維護，並且「殺死令牌」表仍然可以保持爲比完整用戶表小得多（您只需保留比最長允許的令牌生存期）。因此，使令牌無效的能力部分否定了客戶端會話的好處，因爲您必須維護此會話終止狀態。這很可能是比原始會話狀態表小得多的表，因此查找效率更高。

使用JWT令牌的另一個好處是，使用庫可用的庫可能相當容易實現，這些庫可能包含您希望擁有它的每種語言。它也完全脫離了您的初始用戶身份驗證方案 - 如果您轉移到基於指紋的系統，則無需對會話管理方案進行任何更改。

更微妙的好處：因爲JWT可以攜帶「信息」，客戶可以訪問這些信息，所以您現在可以開始做一些聰明的事情。例如，提醒用戶他們的會話將在他們註銷前幾天過期，並根據令牌中的到期日期給他們重新認證的選項。無論你能想象什麼。

簡而言之：智威湯遜回答了其他會話技術的一些問題和缺點。
1.「便宜」身份驗證，因爲您可以消除數據庫往返行程（或至少有一個小得多的查詢表！），這反過來又可以實現水平可伸縮性。
2.防篡改客戶端索賠。

雖然智威湯遜未回答安全存儲或傳輸等其他問題，但並未引入任何新的安全問題。

JWTs存在很多負面影響，但是如果您實施與其他類型的身份驗證相同的安全措施，您將會很好。

最後一點：它也不是曲奇與令牌。 Cookies是一種存儲和傳輸信息的機制，也可用於存儲和傳輸JWT令牌。

Answer 2

簡短回答是：無。

更長的版本是：

我實現了會話管理JWTs閱讀這一建議在the GraphQL docs後：

如果您不熟悉任何的認證機制，我們 推薦使用express-jwt，因爲它很簡單，不會犧牲任何未來的靈活性。

實現確實很簡單，因爲它只增加了一點複雜性。然而，過了一段時間，我（如你）開始想知道這些好處是什麼。原來也有極少數（或可能沒有）的智威湯遜儘可能會話管理得好，因爲這個博客帖子詳細解釋：

Stop using JWT for sessions