JWT 是現在常常使用的使用者驗證之一，其 token 特點是可以讓 API 達到無狀態性 (Stateless)，不需要透過外部儲存服務來紀錄該使用者資料，伺服器只要驗證 token 的簽名是否有被竄改，就能直接讓使用者通行，不過因為 token 本身是無狀態性的，本身並不支援黑名單失效，所以有些會透過 redis 或 database 來做黑名單，但每次都存取 redis 這樣就違背了 JWT 的無狀態性原則，使其變得跟 session 一樣，本篇將介紹如何將 JWT 與 Refresh Token 機制結合來減少詢問 redis 或 database 的次數。
JWT 與 Refresh token 介紹
在介紹機制前，要先了解什麼是 JWT 以及什麼是 Refresh token。
JWT
不知道什麼是 JWT 的話，可以參考此文章：https://yami.io/jwt/
Refresh token
Refresh token 機制最常用於 OAuth 2.0 情境
其有主要兩種 token:
- refresh token：用來取得 access token 的 (時效較長，例：7 天)
- access token：用來存取資源的 token (時效較短，例：30 分鐘)
大致流程如下：
當 client 拿到 access token，就可以一直使用 access token 進行資源存取
而如果 access token 使用過期的話，再重新從 step.4 要求新的 access token
JWT 與 Refresh Token 機制結合
下面介紹一下，如何結合兩個機制來減少存取 redis 的次數
觀察上面 Refresh token 的流程可以注意到大部分跟伺服器請求的時候都是使用 access token 進行資源存取，只有很少的機會會使用 refresh token，兩種 token 使用的比例上可能會是 100:1 或是更高。
由此觀察結果調整，可以在 step.8 的時候，伺服器取得 JWT 時只驗證是否有被竄改以及過期，不檢查是否已被加入黑名單失效，而當 access token 過期了，就會需要透過 refresh token 來要求新的 refresh token (step.4)，伺服器只在這個時機檢查該 refresh token 是否已經被加入黑名單中了，如果已經被加入黑名單便可以不發送 access token，回應無存取權讓使用者重新走登入驗證流程。
並且在結合之後，可以取得 refresh token 的好處，當伺服器程式升級要使用新版本的 JWT Payload 時，可以直接把不相容的 access token 拒絕掉，要求客戶端使用 refresh token 重新要一個新格式的 access token。
總結
由上面介紹歸類出以下優缺點，可以依照自己的情境決定是否使用：
優點：
- 減少存取外部儲存服務驗證是否在黑名單中的次數
- access token 可以達到 Stateless
- 得到 refresh token 的好處，可以更快發送新格式 JWT token
缺點：
- 流程較一般的 JWT 複雜
- 不能夠馬上失效，對於安全要求極高的無法使用