前言
記錄一下前后端分離下————token超時刷新策略!
需求場景
昨天發了一篇記錄 前后端分離應用——用戶信息傳遞 中介紹了token
認證機制,跟幾位群友討論了下,有些同學有這么一個疑惑:token
失效了,應該怎么做?強制定向到登錄頁?
其實理論上如果是活躍用戶,token
失效后,假如用戶正在操作表單,此時突然定向到登錄頁面,那用戶體驗太差了。
實現目標
- 延長
token
過期時間 - 活躍用戶在
token
過期時,在用戶無感知的情況下動態刷新token
,做到一直在線狀態 - 不活躍用戶在
token
過期時,直接定向到登錄頁
登錄返回字段
如何簽發token
,請看上一篇推文,這里不做過多介紹。先看看登錄接口返回的數據如下:
1@Data
2public?class?LoginVo?implements?Serializable?{
3
4????private?static?final?long?serialVersionUID?=?6711396581310450023L;
5
6????//...省略部分業務字段
7
8????/**
9?????*?token令牌?過期時間默認15day
10?????*/
11????private?String?jwt;
12
13????/**
14?????*?刷新token?過期時間可以設置為jwt的兩倍,甚至更長,用于動態刷新token
15?????*/
16????private?String?refreshJwt;
17
18?????/**
19?????*?token過期時間戳
20?????*/
21????private?Long?tokenPeriodTime;
22
23}
具體返回字段的意義請看注釋,這里再簡要說明:
- jwt:用戶正常訪問接口時提交的
token
,過期時間設置長一些,15day吧 - refreshJwt:刷新
token
過期時間可以設置為jwt
的兩倍,甚至更長,用于動態刷新token
時候提交后臺驗證 - tokenPeriodTime:
token
過期時間戳,前端每次調用接口前需要主動判斷是否已經過期,如果過期則提交refreshJwt
訪問token
刷新的接口進行刷新
動態刷新token
前端檢測到token
過期后,攜帶refreshJwt
訪問后臺刷新token
的接口,服務端在攔截器中依然對refreshJwt
進行解析鑒權
- 假如
refreshJwt
也過期了,提示登錄過期,強制跳轉登錄頁 - 假如
refreshJwt
還在有效期,則簽發新的token
返回,前端使用最新的token
進行接口請求
總結
- 如果是活躍用戶,那么允許他在
refreshJwt
過期時間與token
過期時間的差值這段時間內,不停的動態刷新token
,使其做到無感知的狀態下一直保持登錄狀態 - 如果用戶不活躍,在
refreshJwt
過期時間到了,依然沒有使用系統,那么將判定為不活躍用戶,此時應當重定向到登錄頁了
最后
篇幅較短,主要是延續上一篇 前后端分離應用——用戶信息傳遞 遺留問題做一下總結。如果你有更好的做法,歡迎留言告知我,謝謝啦。后續會不定期更新原創文章,歡迎關注公眾號 「張少林同學」!