什麼是jwt以及工作流程？
可以看下面的鏈接
http://blog.leapoahead.com/2015/09/06/understanding-jwt/
JWT是否要設置過期？
如果不設置過期的話，jwt一旦被中間人獲取，就可以永遠使用，服務端是無法分辨出來的，因爲jwt的無狀態特性。
所以過期時間是要設置的，而且短些比較好。
token過期了，理論上要跳到登錄頁面重新登錄，重新換取token的。比如我們設置1小時過期，用戶每過1小時就需要重新輸入密碼，是不是感覺很奇怪呢？討論怎麼處理之前，我們先看下又一個問題，假如要登出怎麼辦？
怎樣處理登出？
我搜了很多的文章，總結有以下幾種
1.從客戶端把jwt刪除，服務端不做處理
問題就是，自己騙自己，被刪除的這個token還能用，如果你設置了過期時間，那就還好，等到期就失效了，如果你沒有設置過期時間，那就永遠有效，這也是jwt設置較短過期時間的又一個好處，但是又會有jwt經常過期，登錄的問題
2.創建一個黑名單，在驗證jwt之前，先檢查黑名單裏是否存在，如果不在就往下走，在的話直接認證不通過
問題就是，每次請求都多了一步檢查黑名單，而且最重要的是違背了jwt的設計思想，jwt的無狀態特性
3.給jwt設置一個短的過期時間，而且經常刷新獲取新token，即refreshtoken
這樣就可以和1結合，那如何換取新token呢？這個和怎麼處理過期一起討論
怎樣處理過期？
使用refresh token，流程如下
不過我對這裏有一個疑惑，在db存儲refresh token 就不算違背jwt的無狀態特性了嗎？
補充下圖，這裏的狀態指的是驗證服務器，而不是應用服務器，應用服務器還是無狀態的，refresh token只能請求 ，auth server，在應用服務器無作用的。
安全性問題
Persisting JWT token in localstorage (prone to XSS) < Persisting JWT token in an HttpOnly cookie (prone to CSRF, a little bit better for XSS) < Persisting refresh token in an HttpOnly cookie (safe from CSRF, a little bit better for XSS).
w w w w wjwt存儲到內存中，refresh token 可以使用httponly持久化cookie， 每次啓動app時可以用refresh token，（如果refresh token沒過期的話，過期就跳轉到登錄頁面），獲取新的jwt token和refresh token，流程如下
參考鏈接：
https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/#refresh_token_persistance
https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens/52407314#52407314
https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/