jwt是生成和校驗解密token的工具，redis是快取，他們之間並不衝突，加起來一起用效果更好，僅僅用token是不夠的，因為一但設定token意味著其登入過期時間也就確定了。就無法讓其在有效期內失效，這樣不合理的。。所以可以通過redis記錄token，控制其的有效性，和記錄一些資訊。所以 token加redis才是正確的選擇。

jwt屬於無狀態設計，使用者登陸的資訊關鍵存放在jwt加密資料裡，這種設計下伺服器不需要儲存jwt密文，只需要解密就能拿到授權資訊等使用者資訊。這種設計是一種利用計算力減少token設計下資料庫及快取的壓力和設計複雜度，因此它的本質就是不儲存登陸授權，而通過密文字身儲存授權資訊。

token加redis設計，是一種登陸後分配隨機token，然後記錄token與使用者資訊對應關係的設計。

很明顯，這兩張設計的區別就在於token實際上是需要伺服器儲存，每次驗權需要查詢資料庫。jwt不需要伺服器儲存，資訊本身就儲存於jwt本身，這種模式無需使用資料庫。

但是這種流行的jwt有一個設計上的缺陷，他通過密文傳輸使用者資訊，那麼伺服器在這種基礎結構下是無法做到關閉使用者登陸授權的操作，如果使用者的jwt密文被偷竊，那麼黑客就能以使用者身份登陸，並且即使知道密文丟失，也無法關閉被偷竊的jwt密文。為了應對這一問題，可以使用jwt內部驗證有效期和jwt黑名單模式，但是有效期始終無法做到及時停止jwt授權，這是一個治標不治本的方法。而jwt黑名單模式，則需要資料庫或記憶體儲存黑名單，那麼，這實際上違背了jwt的免資料庫設計原則。

因此，如果嚴格按照兩種模式設計，jwt更適合低安全級別的伺服器設計，如普通的部落格、閱讀器等等，這種服務允許不嚴格的登陸授權，即使密文丟失也不會造成使用者的嚴重損失，卻能獲得較高的服務效能。

token模式，必須配合資料庫進行儲存和查詢，因此效能較低，但token模式卻能做到及時的授權關閉，已經登陸授權可見可查，每一次token都會有對應的記錄。因此token模式適合較高安全度和使用者登陸等資訊分析的系統，如政府系統，支付系統等不可能允許高許可權的token被偷竊卻不能及時關閉授權。

jwt，適合輕量的系統和許可權不嚴格系統。

token，適合重量系統和許可權有嚴格要求的系統。

token：

普通的token方式採用的是：登入-->生成隨機字串（token）-->伺服器儲存token與使用者資訊的對應關係

對應使用者利用token校驗的流程是 token-->查詢token對應使用者資訊-->各系統根據使用者資訊進行業務處理。

很明顯可以看出，token模式下的字串實際上不需要和使用者資訊有任何關聯，生成的token字串的要求就是唯一，不能被其他使用者佔有，否則就會出現使用者登入後實際上是以其他人身份進行業務處理。如果字串是隨機生成，那麼黑客就無法猜測token的生成規律，也無法從token直接猜測到使用者相關資訊。

jwt:

jwt採用的生成：登入-->生成帶有使用者資料的加密字串（該字串伺服器並不儲存，直接下發給客戶端）

校驗：客戶端將儲存的jwt密文帶上-->伺服器解密密文，獲取到使用者資訊

可以看出，jwt的憑證不僅要求唯一，還要求密文字身實際上是帶有了使用者資訊，當然這塊可以是非敏感資訊，這只是實現上的細節區別，和結構本身沒有特別大的關聯。伺服器本身並沒有儲存這次jwt密文，每次伺服器的處理都是直接解密jwt密文。這樣做的好處就是服務架構內直接拋棄了登入相關的傳統token系統，並且伺服器不再管理登入狀態，token有效狀態等問題。

而jwt帶來的問題，憑證實際上的一串密文，更多的使用者資訊或session資訊需要更大的密文來儲存，進而每次請求都帶上jwt就會使網路傳輸的內容變大，加大了網路開銷；憑證是一串密文，那麼如果黑客破解了伺服器的加密方式，那麼密文實際上就是使用者資訊在網路上傳輸，黑客可以直接偽造jwt登入或通過jwt密文獲取到使用者資訊；jwt本身不管理jwt的有效性，一旦密文被偷竊，無法做到關閉掉黑客的授權。

謝邀。

JWT（Json Web Token），是為了在網路應用環境間傳遞宣告而執行的一種基於JSON的開放標準。由頭部（Header）、負載（Payload）、簽名（Signature）三部分構成，其中每一部分使用Base64編碼處理。

Header 中儲存了所使用的加密演算法和 Token 型別。

Payload是負載，JWT 規範規定了一些欄位，並推薦使用，當然每一個開發者也可以自己指定欄位和內容。需要注意的是，該部分內容只經過了 Base64 編碼，相當於明文儲存，所以不要放置敏感資訊。

而Signature，則是使用Base64編碼後的Header 和Payload以及一個祕鑰，使用header中指定簽名演算法進行簽名。

可用下面的圖對上述概念進行總結：

JWT屬於無狀態，不依賴Cookie，可以在禁用Cookie的瀏覽器中執行，可有效防止CSRF攻擊；服務端不用儲存session，易於擴充套件；相比XML更加簡潔，更加適合在HTTP環境中傳輸。

那麼JWT都存在哪些問題呢？主要集中在以下幾個方面

無法作廢已頒佈的Token，比如說使用者登出這個功能，傳統的基於session的方案，只需在服務端刪除該session即可，因為狀態在服務端儲存。而JWT就比較難辦到，因為JWT是無狀態的，儲存在客戶端，即使被刪除了，一定有效期內服務端並不知道，它仍然是有效的。

無法應對過期的資料

安全機制不夠高

Restful API無狀態驗證

一次性驗證：比如使用者註冊某網站後需要傳送一封郵件讓其啟用賬戶，通常該郵件中包含一個連結，該連結往往含有以下幾個特點：能夠標識唯一使用者、不能被篡改、具有時效性。

自己生成一個32位的key，value為使用者資訊，客戶端訪問時服務端首先判斷Redis裡是否有該Token，如果有，則載入該使用者資訊完成登入。服務需要儲存下發的每個token及對應的value，維持其過期時間。

Jwt是帶有簽名的客戶身份令牌。安全性還是比較高的。但是需要正確使用。它本身主要是證明客戶身份，並不包含機密資訊。如果需要避免重複使用，可以提供時間戳，可以一次性使用。這樣很多安全問題就都解決了。現在很多服務都使用jwt認證。

都可以，通常情況下正式點我會用shiro+redis實現許可權session認證管理，免去了自己實現session認證的過程，並且它還提供了一些進階的功能。簡陋點的話，redis+token就可以了，要自己去設計實現，通常配合攔截器實現session認證。