?引言

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

十載的薛城網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整薛城建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)公司從事“薛城網(wǎng)站設(shè)計”,“薛城網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

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

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

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

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

30s 圖解 Token 認證

首先，什么是 Token？

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

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

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

基于 token 的認證步驟如下圖，配合文字食用：

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

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

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

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

附加閱讀

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

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

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

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

Refresh Token

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

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

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

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

Refresh Token 的過期時間設(shè)置的長一點比如一兩個月，Access Token 的過期時間設(shè)置短一點比如一周，這樣可以縮短 Access Token 的過期時間保證安全，同時又不會因為頻繁過期重新要求用戶登錄

具體認證步驟如下圖，配合文字食用：

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

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

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

4）服務(wù)端：

• 驗證 Access Token 有效：正常返回數(shù)據(jù)
• 驗證 Access Token 過期：拒絕請求

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

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

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

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

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

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

網(wǎng)頁題目：如何用30s給面試官講清楚什么是Token
文章位置：http://uogjgqi.cn/article/cdggeoo.html