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的來解決
好的，真的要結束了，拜拜拜拜。。。