前言

記錄一下前後端分離下————token超時刷新策略！

需求場景

token失效了，應該怎麼做？強制定向到登錄頁？

其實理論上如果是活躍用戶，token失效後，假如用戶正在操作表單，此時突然定向到登錄頁面，那用戶體驗太差了。

實現目標

• 延長token過期時間
• 活躍用戶在token過期時，在用戶無感知的情況下動態刷新token，做到一直在線狀態
• 不活躍用戶在token過期時，直接定向到登錄頁

登錄返回字段

如何簽發token，請看上一篇推文，這裡不做過多介紹。先看看登錄接口返回的數據如下：

@Data
public class LoginVo implements Serializable {
 private static final long serialVersionUID = 6711396581310450023L;
 //...省略部分業務字段
 
 /**
 * token令牌 過期時間默認15day
 */
 private String jwt;
  

 /**
 * 刷新token 過期時間可以設置為jwt的兩倍，甚至更長，用於動態刷新token
 */
 private String refreshJwt;
 
 /**
 * token過期時間戳
 */
 private Long tokenPeriodTime;
}

具體返回字段的意義請看註釋，這裡再簡要說明：

• jwt：用戶正常訪問接口時提交的token，過期時間設置長一些，15day吧
• refreshJwt：刷新token 過期時間可以設置為jwt的兩倍，甚至更長，用於動態刷新token時候提交後臺驗證
• tokenPeriodTime：token過期時間戳，前端每次調用接口前需要主動判斷是否已經過期，如果過期則提交refreshJwt訪問token刷新的接口進行刷新

動態刷新token

前端檢測到token過期後，攜帶refreshJwt訪問後臺刷新token的接口，服務端在攔截器中依然對refreshJwt進行解析鑑權

• 假如refreshJwt也過期了，提示登錄過期，強制跳轉登錄頁
• 假如refreshJwt還在有效期，則簽發新的token返回，前端使用最新的token進行接口請求

總結

• 如果是活躍用戶，那麼允許他在refreshJwt過期時間與token過期時間的差值這段時間內，不停的動態刷新token，使其做到無感知的狀態下一直保持登錄狀態
• 如果用戶不活躍，在refreshJwt過期時間到了，依然沒有使用系統，那麼將判定為不活躍用戶，此時應當重定向到登錄頁了