【通俗易懂】JWT-使用的可能正確姿式

JWT，英文全稱JSON Web Token，一種開放行業標準。

應用場景爲單點登陸，API受權等。

假想的黑粉：「因此這篇文章是要詳細介紹JWT是什麼嗎？」

非也非也，若是各位看官還不瞭解什麼是JWT以及JWT的工做流程，還請本身先去GOOGLE下哈

我是不會跑題的，準備愉快地進入主題

---

JWT的優勢：用戶會話信息保存在客戶端，服務端不再用操心用戶的會話信息，即服務端無狀態

JWT的缺點：只能被動等到token過時，不能主動失效token

假想的黑粉：「這個缺點有啥影響嗎？」

固然啦，想一想退出登陸，是否是就是一種主動失效的應用場景

假想的黑粉：「好像是，但這個容易解決啊，把token保存在後端服務，如redis，退出時在redis中把它幹掉不就完事了嗎」<（￣︶￣）>

能夠啊，腦殼轉得這麼快，好像能夠解決問題

等等，好像哪裏不對，這樣又把會話信息存放在服務端，JWT的優點木有了，那要它何用？用傳統的session方案就好了啊

簡單講講服務端有狀態的傳統session方案：用戶登陸後，服務端把用戶會話信息存放在session中（保存在服務端的某個地方，例如緩存），而後把session ID存放於cookie中，後續用戶的請求中都會攜帶cookie，服務端經過cookie中的session ID便可判斷用戶的登陸狀態

假想的黑粉：「能解決問題就行，那麼糾結幹嗎呢？」

這。。。不行不行，不能爲了用而用啊

假想的黑粉：「那你有解決方案嗎？棄JWT而用session？」

我以爲吧，仍是有使用的可能正確姿式的，先來個華麗麗的分隔線

---

先來簡單看一下JWT校驗token的原理：

• 簽名：數據 + 密鑰 => Hash

• 驗證：數據 + 密鑰 => hash => compare 攜帶的簽名

由上圖可見存放於服務端的密鑰只要不被竊取，數據就沒法被篡改，一旦修改了數據，則compare步驟必定不經過，則該token無效

假想的黑粉：「哦，我知道了，那就篡改數據，token自動就失效了」

你不是認真的吧？在客戶端修改？Oh no！在服務端修改？Oh no！

假想的黑粉：「難道是修改密鑰？密鑰但是全局共用的哦，一經修改，其它頒發的token也跟着失效，這但是災難性的」

差很少猜對了，全局不行，那就不要全局，來個一一對應， 一個用戶專屬一個惟一的密鑰。

當要主動失效A用戶的token，只要修改A用戶所對應的密鑰便可，仔細想一想，這個方案其實挺優雅的，只是稍微修改了下密鑰的獲取方式，JWT的優點能夠繼續發揮，咱們來用下圖做個形象的理解吧

token驗證流程比全局密鑰的模式多了一步：從Cache中取出某個用戶的密鑰。是否會對性能形成影響，就須要在實際的應用場景中進行評估了

好了，到此結束，謝謝觀看

假想的黑粉：「等等啊，我想問續期怎麼破啊，好比API受權續期問題」

續期問題可用：失效token，從新獲取新token的來解決

好的，真的要結束了，拜拜拜拜。。。