?引言

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

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

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

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

為此，Token 應運而生。

30s 圖解 Token 認證

首先，什么是 Token？

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

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

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

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

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

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

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

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

附加閱讀

Token 認證服務端代碼

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

退出登錄實質就是刪除 Redis 中存儲的 token，完整內容如下：

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

Refresh Token

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

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

我們把之前的那個 Token 稱之為 Access Token，業務接口用這個 Access Token 進行認證鑒權

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

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

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

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

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

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

4）服務端：

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

客戶端：重新發起請求，在 HTTP Header 中攜帶 Refresh Token 發送給服務端

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

客戶端：獲得服務端返回的新的 Access Token，重新發起請求并攜帶新的 Access Token

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

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

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