夕陽雨晴2021-05-04 09:12:551. 問題描述
jwt與token+redis，哪種方案更好用？
問題結論
剛好最近有專案使用了jwt，而且是定製化的jwt的認證機制，就個人的理解而言，各自有其優缺點，並且針對不同的場景需要進行約束性開發，如使用者剔除、同一使用者每2h只生成一次jwt等。
2. Token機制簡述
2.1 Token的用途
使用者在登入APP時，APP端會發送加密的使用者名稱和密碼到伺服器，伺服器驗證使用者名稱和密碼，如果驗證成功，就會生成相應位數的字元產作為token儲存到伺服器中，並且將該token返回給APP端。
以後APP再次請求時，凡是需要驗證的地方都要帶上該token，然後伺服器端驗證token，成功返回所需要的結果，失敗返回錯誤資訊，讓使用者重新登入。其中，伺服器上會給token設定一個有效期，每次APP請求的時候都驗證token和有效期。
在儲存的時候把token進行對稱加密儲存，用到的時候再解密。文章最開始提到的簽名sign：將請求URL、時間戳、token三者合併，透過演算法進行加密處理。
2.2 token+redis機制
使用者驗證通過後，服務端透過如uuid相關的方法，生成token，儲存使用者資訊。
當請求服務時，客戶端將token帶上來，進行查詢驗證，如token存在並在有限期內，請求有效，否則請求非法。
token + redis機制是中心化的，每次驗證token有效性時，都需要訪問redis，其核心優點實服務端可以主動讓token失效，缺點是每次都要進行redis查詢。佔用redis儲存空間。
2.3 jwt機制
這是一種無狀態身份驗證機制，因為使用者狀態永遠不會儲存在伺服器記憶體中。 伺服器受保護的路由將在授權頭中檢查有效的JWT，如果存在，則允許使用者訪問受保護的資源。 由於JWT是獨立的，所有必要的資訊都在那裡，減少了多次查詢資料庫的需求。
Java jwt普遍選用java-jwt工具包依賴，gradle依賴：compile ‘com。auth0：java-jwt：3。2。0’
使用者發起登入請求，驗證通過後，服務端建立一個加密後的JWT資訊，作為Token返回。在後續請求中JWT資訊作為請求頭，發給服務端。服務端拿到JWT之後進行解密，正確解密表示此次請求合法，驗證透過；解密失敗說明Token無效或者已過期。
jwt的有點主要有：a。其是去中心化的，便於分散式系統使用； 2。 基本資訊可以直接放在token中。 user_id，session_id； 3。 功能許可權資訊可以直接放在token中。用bit位表示使用者所具有的功能許可權。 其缺點有：服務端無法主動讓token失效，另一個是無法很好的控制payload的資料量。
3. 小結
jwt和token+redis兩種方案，沒有最優，只有結合不同的業務場景，需求最適合的方案。就比如token 2h過期，同一使用者每1。5h只生成一次token，當兩次token並存時，同時有效。大家可以考慮在這兩種方案的前提下，分別如何實現？
作者：夕陽雨晴，歡迎關注我的頭條號：偶爾美文，主流Java，為你講述不一樣的碼農生活。
猿獅兄2021-01-26 22:56:32兩種方式的優缺點你在問題中說的很清晰，適用的系統根據實際場景我覺得不難分析。以下為我自己的一些思考。
在擁有龐大使用者量的系統中，使用者保持登入態僅作為跟蹤分析使用者行為，不會對賬戶本身造成過大影響。那麼我認為它的登入剔除操作不重要，我也不允許它不斷的為校驗使用者來刷我的庫甚至redis，用jwt很合適。
預警系統對行為上報異常賬戶進行監測，只監測一批異常使用者，我需要知道它的實時狀態，隨時準備token失效，那麼token+redis就有必要了。
一般的通用系統
，我推薦的採用jwt+redis的組合方案。jwt進行認證，redis作為證書撤銷列表（CRL）來使用，也就是黑名單。
從通用系統出發，認證是個頻繁操作，幾乎每次的請求都需要獲取登入認證資料，在令牌有效範圍內進行拉黑，這樣的令牌正常跟使用者量來比較，為數不多。
具體認證方案步驟如下:
step1：使用者登入，驗證透過，由認證伺服器jwt方式簽發token，時效30分鐘。
step2：使用者行為，jwt驗證透過，CRL中token不存在，向後執行coding…
step3：發現使用者異常，使用者token寫入CRL，時效30分鐘。這樣可以保證簽發的token可以在有效期內一直被拉黑。
step4：使用者行為，jwt透過，CRL不透過，重新登陸或者其他業務邏輯。
對比單純jwt方式
，組合方案會多出一次redis請求，這樣對分散式的登入驗證有一定的破壞，增加了一次網路開銷，需要根據業務預計的黑名單換入換出頻率和黑名單總容量來評估使用這種方案是否合適。
對比單純token+redis方式
，組合方案用一次jwt摘要演算法（通常一次本地SHA256）來替換一次查庫校驗，資訊的實時性不強，不是每次獲取最新資訊，但是速度會快，用本地的一次計算減少最少一次網路IO，資料查詢，給資料庫的壓力也會大減，注意儲存好私鑰。
解決方案可以多種多樣，我們也可以從其他方向尋找靈感，例如OAuth2，PKI/CA 體系證書的驗證。一個實現方案+配套系統的配合就可以打造出想要的效果。
歡迎隨時討論。
Ex無毀湖光2021-01-26 18:08:18為什麼不用jwt+redis？
思路其實和token那個差不多
生成時把兩個token（訪問token和重新整理token）都存redis，重新整理過後把之前的訪問token丟redis的黑名單裡，生成的時候重新整理token還在有效期內就生成一個訪問token。
舉例子：
訪問只能用訪問token，時間假設30分鐘，重新整理token假設30天，只能用於重新獲取訪問token。
第一次訪問：
獲取兩個token，並存入redis中。
第二次訪問：
只使用訪問token，當訪問token有效時間在1分鐘以內時，重新整理token，獲取一個新的token，重新整理時把老訪問token丟黑名單，時效一分鐘。
修改密碼退出登入等：
同理檢查黑名單，在黑名單裡直接就不解析token是否有效，直接返回無效token就行。只要重新整理就把以前的token丟黑名單，重新整理時，重新整理token作為訪問介面的token，老token作為傳遞的憑證，防止瘋狂重新整理導致你的redis黑名單無限增長。
這樣有一個好處，你不用頻繁的訪問資料庫來判斷token是否有效，只需要計算jwt是否有效和配合redis來維護有效的token
浩瀚無邊的浩瀚2021-03-14 15:03:49各有各的優缺點，我個人更傾向於jwt，因為我更多參與的是比較小的專案，公司技術開發的資金有限，再說也沒有人會攻擊，因為不入駭客的眼睛，而且就算攻擊，99%不能夠直接破解你的jwt加密技術，最多獲取到別人的jwt去偽造別人的使用者操作，能做到這步也不容易，再加上我們的使用者更少，token+redis其實對於我們也是一樣的，因為流量不大，伺服器的開銷也不大，但相比jwt更方便，也不用擔心redis服務掛了。
勤奮的TommyWang2021-01-26 19:09:35jwt是無狀態的，擴充套件很方便，缺點是一旦簽發在達到有效期前不能撤銷，redis+token是有狀態的，token透過redis來進行集中維護，系統擴充套件性受制於redis叢集的併發能力，優點是可以隨時撤銷簽發的token
白衣敲木魚2021-01-26 18:55:05看場景：
如果做分散式的話可以考慮用redis，當然nginx也可以
token+redis需要已經去設定規則跟過期時間，並且可以實現分散式
jwt內部有已經規則跟生命週期但做不到分散式
［紅臉］
積年程式開發老妖精2021-05-26 19:53:22從使用角度來說，沒嘛區別，都是為了解決session共享的問題。我覺得，token+redis從安全性上比jwt要高些，jwt存在資訊洩露的可能性。token+redis中的token不具有現實意義，但也最好加密後再發到前端。
