refresh token是token之后的一個(gè)進(jìn)一步的發(fā)展。它主要是為了讓用戶無感知的延長(zhǎng)登錄狀態(tài)的有效期。
于是現(xiàn)在的流程（省略掉了一些細(xì)節(jié)）是：
賬號(hào)密碼登錄。
服務(wù)器返回access_token和refresh_token兩個(gè)字符串，都要存到本地而且永久存儲(chǔ)。
access_token在服務(wù)器的生命是1天，refresh_token在服務(wù)器的生命是7天。這個(gè)天數(shù)可以自己公司自己定。將生命值一起存到本地緩存，比如
{
access_token:{
value: 'xxx',
expires: '一天以后的時(shí)間戳'
},
access_token:{
value: 'ooo',
expires: '7天以后的時(shí)間戳'
}`
}
發(fā)請(qǐng)求之前要做一些本地的判斷，要判斷access_token是否過期，沒過期的話，請(qǐng)求要header攜帶access_token，服務(wù)器判斷access_token是否過期，過期的話，返回401錯(cuò)誤。
你的axios要攔截401錯(cuò)誤，當(dāng)攔截到之后，立即向一個(gè)特設(shè)的api發(fā)請(qǐng)求，此時(shí)header攜帶的是refresh_token。
服務(wù)器判斷refresh_token是不是過期，如果沒有過期，那么返回新的access_token和新的refresh token，然后把掛起的請(qǐng)求重新發(fā)出去。這里注意，雖然refresh token的有效期是access_token的好幾倍，但是它往往撐不到生命結(jié)束，因?yàn)閍ccess_token一天就過期了，那么refresh token即便沒有過期，也會(huì)被刷新成新的refresh token。
之前說了，有些細(xì)節(jié)我省略掉了，全部流程可以看這個(gè)圖。這個(gè)圖的爭(zhēng)議部分就是access_token的“是否過期”和“是否即將過期”，你可以判斷兩次，也可以只判斷是否過期，都成。
另外注意：
axios的攔截器怎么寫，其實(shí)還是很簡(jiǎn)單的，因?yàn)閿r截器本質(zhì)就是掛起請(qǐng)求，所以中間你插一個(gè)請(qǐng)求新的access_token的過程是沒問題的。
圖里沒有提到refresh_token本地過期的判斷，應(yīng)該考慮上，如果本地過期，就立即跳到重新登錄。
有同學(xué)說，那我一打開項(xiàng)目就已經(jīng)refresh token過期了，怎么判斷？
廢話么這不是，項(xiàng)目加載過程中就會(huì)做ajax請(qǐng)求啊，請(qǐng)求如果過期了就跳轉(zhuǎn)到登錄啊。就是上面的流程。有同學(xué)說，我不用refresh_token行不行？
當(dāng)然行，refresh_token就是為了“無感知的延長(zhǎng)用戶登錄有效期”，不用的話，更簡(jiǎn)單，access_token一天之后一定過期，一定要重登陸。有同學(xué)說，不用refresh token，只是服務(wù)器在access_token臨近過期的時(shí)候延長(zhǎng)access_token的服務(wù)器有效期行不行？
也行！但是這里面就有個(gè)問題，就是服務(wù)器要判斷你的access_token是不是臨近過期，這就需要任何一個(gè)請(qǐng)求發(fā)到服務(wù)器都要判斷一次token的有效期，是不是非常浪費(fèi)服務(wù)器性能？相對(duì)而言，瀏覽器向特定接口發(fā)一次請(qǐng)求，是不是非常節(jié)省服務(wù)器性能？有同學(xué)說，還是不想用refresh token，只在本地判斷access_token是不是臨近過期行不行？只要本地臨近過期，就向服務(wù)器發(fā)送請(qǐng)求，請(qǐng)求access_token延期，行不行？
行，但是安全性低。這就涉及到refresh_token的另一個(gè)作用，提升安全性。因?yàn)閍ccess_token你每天可能會(huì)發(fā)200次，但是refresh_token你每天發(fā)一次（上面說了，雖然refresh_token有7天生命，但往往1天就隨著access_token刷新了），你說哪個(gè)安全？有同學(xué)說，如果我正在向服務(wù)器發(fā)送多個(gè)請(qǐng)求，比如同時(shí)發(fā)了10個(gè)請(qǐng)求，那么我們知道，請(qǐng)求服務(wù)器特定接口，是需要時(shí)間的，比如用時(shí)1秒，這1秒內(nèi)10個(gè)請(qǐng)求都獲得了401錯(cuò)誤，axios會(huì)向特定接口發(fā)10個(gè)請(qǐng)求，這時(shí)候服務(wù)器會(huì)返回10個(gè)不同的access_token嗎？
這就需要服務(wù)器做處理了，也就是后端同學(xué)需要考慮的事情，他要保證服務(wù)器發(fā)回來的10個(gè)token的值必須是一致的。也就是說，服務(wù)器新生成的access_token和refresh token在短時(shí)間內(nèi)（比如3秒內(nèi)）是不允許改變的。有同學(xué)說，拿著access_token和refresh_token是不是能永久登錄了？如果被外人拿到怎么辦？
這就需要服務(wù)器判斷用戶異常行為，然后警報(bào)。這跟cookie/session方案的安全性是一樣的，沒有警報(bào)的話，誰知道是不是你本人呢？阿里騰訊也不敢說異地登錄的就一定是你本人，或者一定不是你本人吧？
再有，你用賬號(hào)密碼登錄的話，是一定會(huì)刷新access_token和refresh_token的，那么別人拿的access_token和refresh_token也就立即失效了。有同學(xué)說，怎么注銷access_token呢？
全文說的access_token和refresh_token，并不是JWT方案，而是傳統(tǒng)token方案，JWT方案才有“注銷困難”（但也是有辦法的）的問題，因?yàn)镴WT在服務(wù)器只存在計(jì)算式的校驗(yàn)，而不是跟已有數(shù)據(jù)比對(duì)式的校驗(yàn)，JWT是計(jì)算驗(yàn)證，不是比對(duì)驗(yàn)證。這里不提JWT方案，只說傳統(tǒng)token方案的話，因?yàn)閠oken是在服務(wù)器是有儲(chǔ)存的，發(fā)到服務(wù)器的token是要進(jìn)行比對(duì)的。所以注銷很容易啊，把服務(wù)器存的那份刪掉就行了。
