?引言

前文介紹了 Session-Cookie 的認(rèn)證過程，簡單回顧下基本步驟：

• 客戶端（瀏覽器）向服務(wù)器發(fā)送用戶名和密碼
• 服務(wù)器驗(yàn)證通過后，創(chuàng)建 Session 對(duì)象，在 Session 中保存該用戶相關(guān)的數(shù)據(jù)，比如用戶角色、登錄時(shí)間等等
• 服務(wù)器向用戶返回這個(gè) Session 對(duì)象的唯一標(biāo)識(shí) SessionId，并寫入客戶端的 Cookie
• 客戶端隨后的每一次請(qǐng)求，都會(huì)通過 Cookie，將 SessionId 傳回服務(wù)器
• 服務(wù)器收到 SessionId，并據(jù)此找到 Session 對(duì)象，由此獲取到用戶信息

這種方法的缺點(diǎn)就是分布式集群情況下無法保證每臺(tái)服務(wù)器都擁有相同的 Session，上篇文章也簡單介紹了幾種 Session 如何在多個(gè)服務(wù)器之間共享的方法。

顯然，Session 的維護(hù)給服務(wù)端造成了很大的困擾，有沒有更好的方案，能不能直接不用 Session？

為此，Token 應(yīng)運(yùn)而生。

30s 圖解 Token 認(rèn)證

首先，什么是 Token？

簡單來說，Token 其實(shí)就是一串字符串，一個(gè)令牌，客戶端訪問服務(wù)器時(shí)，驗(yàn)證通過后服務(wù)端會(huì)為其簽發(fā)一張令牌，之后，客戶端就可以攜帶這個(gè)令牌訪問服務(wù)器，服務(wù)端只需要驗(yàn)證令牌的有效性即可。

一般來說，Token 的組成是這樣的：

uid? (用戶唯一的身份標(biāo)識(shí)) + time? (當(dāng)前時(shí)間的時(shí)間戳) + sign (簽名，Token 的前幾位以哈希算法壓縮成的一定長度的十六進(jìn)制字符串)

基于 token 的認(rèn)證步驟如下圖，配合文字食用：

1）客戶端（瀏覽器）：用戶向服務(wù)器發(fā)送登錄信息（用戶名和密碼）來請(qǐng)求登錄校驗(yàn)；

2）服務(wù)端：驗(yàn)證用戶名密碼等，驗(yàn)證成功后生成 token 并返回給前端，這個(gè) token 就是之后鑒權(quán)的唯一憑證。服務(wù)端需要將這個(gè) token 及其對(duì)應(yīng)的用戶信息存儲(chǔ)在數(shù)據(jù)庫或者緩存中；

3）客戶端：將服務(wù)端返回的 token 存在 cookie 或者 localStorge 中，之后的每次請(qǐng)求之前，從 cookie 或者 localStorge 取出 token 將其設(shè)置進(jìn) HTTP Header 中（可以通過 HTTP 請(qǐng)求攔截器實(shí)現(xiàn)）；

4）服務(wù)端：服務(wù)端接收到來自客戶端的請(qǐng)求，從 HTTP Header 中取出 token，去緩存或者數(shù)據(jù)庫中進(jìn)行驗(yàn)證（該 token 是否存在 / 根據(jù)該 token 能否找到對(duì)應(yīng)的用戶），如果驗(yàn)證通過則執(zhí)行進(jìn)一步的業(yè)務(wù)操作，如果不通過則拒絕執(zhí)行。

附加閱讀

Token 認(rèn)證服務(wù)端代碼

先來看登錄，就是先判斷用戶名密碼是否正確，如果正確，那么會(huì)生成并返回一個(gè)字符串做為 token（這里偷個(gè)懶就直接用 UUID 來生成了），并將其和用戶信息（這里就簡單的存了 username）一并存入到數(shù)據(jù)庫 or 緩存中（這里采用 Redis，過期時(shí)間可自行配置）。

退出登錄實(shí)質(zhì)就是刪除 Redis 中存儲(chǔ)的 token，完整內(nèi)容如下：

再來個(gè)攔截器，前端拿到后端返回的 token 后每次請(qǐng)求前都會(huì)在 HTTP header 中帶上這個(gè) token，服務(wù)端設(shè)置個(gè)攔截器取出 Header 中的token，然后去 Redis 中進(jìn)行判斷這個(gè) token 是否存在，若存在則允許進(jìn)行下一步操作，：

Refresh Token

一般來說，為了安全起見，防止 token 被攻擊者盜用，token 的有效期不會(huì)設(shè)置的太長，這樣就會(huì)由于 token 過期導(dǎo)致用戶需要重新登錄從而生成新的 token。

如何才能做到不需要用戶去頻繁的登錄呢，Refresh Token 機(jī)制出現(xiàn)了。

我們把之前的那個(gè) Token 稱之為 Access Token，業(yè)務(wù)接口用這個(gè) Access Token 進(jìn)行認(rèn)證鑒權(quán)

而 Refresh Token 呢，就是一個(gè)專門用來在 Access Token 過期后重新獲取新的 Access Token 的 Token

Refresh Token 的過期時(shí)間設(shè)置的長一點(diǎn)比如一兩個(gè)月，Access Token 的過期時(shí)間設(shè)置短一點(diǎn)比如一周，這樣可以縮短 Access Token 的過期時(shí)間保證安全，同時(shí)又不會(huì)因?yàn)轭l繁過期重新要求用戶登錄

具體認(rèn)證步驟如下圖，配合文字食用：

1）客戶端（瀏覽器）：用戶向服務(wù)器發(fā)送登錄信息（用戶名和密碼）來請(qǐng)求登錄校驗(yàn)；

2）服務(wù)端：驗(yàn)證用戶名密碼等，驗(yàn)證成功后生成 Access Token 和 Refresh Token 并返回給前端，服務(wù)端需要將這兩個(gè) token 及其對(duì)應(yīng)的用戶信息存儲(chǔ)在數(shù)據(jù)庫或者緩存中；

3）客戶端：將服務(wù)端返回的 Access Token 和 Refresh Token 存在 cookie 或者 localStorge 中，之后的每次請(qǐng)求之前，從 cookie 或者 localStorge 取出 Access Token 將其設(shè)置進(jìn) HTTP Header 中（可以通過 HTTP 請(qǐng)求攔截器實(shí)現(xiàn)）；

4）服務(wù)端：

• 驗(yàn)證 Access Token 有效：正常返回?cái)?shù)據(jù)
• 驗(yàn)證 Access Token 過期：拒絕請(qǐng)求

客戶端：重新發(fā)起請(qǐng)求，在 HTTP Header 中攜帶 Refresh Token 發(fā)送給服務(wù)端

服務(wù)端：驗(yàn)證客戶端傳來的 Refresh Token ，驗(yàn)證成功后生成新的 Access Token 并返回給客戶端

客戶端：獲得服務(wù)端返回的新的 Access Token，重新發(fā)起請(qǐng)求并攜帶新的 Access Token

如何理解 Refresh Token 的必要性，或者說為什么使用 Refresh Token 能夠更安全？

Access Token 每次訪問都要帶著，因此更容易被盜取

而 Refresh Token 客戶端獲取到之后就保存起來，Access Token 失效之后，才會(huì)用到 Refresh Token，所以粗略來說 Refresh Token 只會(huì)在網(wǎng)絡(luò)上傳輸兩次，一次是你獲取的時(shí)候，一次是你使用的時(shí)候（從上圖可以看出來），因此 Refresh Token 被盜的風(fēng)險(xiǎn)遠(yuǎn)遠(yuǎn)小于 Access Token