這節(jié)課開始帶大家設計實現一個套支持多平臺登錄，Token泄露檢測、同平臺多設備登錄互踢功能的用戶認證體系，這套用戶認證體系既可以在你未來開發(fā)產品時直接應用，也可以在其基礎上根據需要擴展出其他功能.它會作為我們后面商城App后端服務的的用戶認證體系，同時又足夠獨立，能拿到自己的項目中去快速把用戶認證給搭建起來。

說到Token，很多人一開始想到的可能是JWT -- JSON Web Token。

JWT因為其本質是存儲在客戶端cookie中，發(fā)布出去后服務端無法對其進行主動過期等控制，所以應用場景跟這里介紹的用戶認證體系不一樣，我們今天介紹的這套用戶認證體系，在用戶體驗、安全性和穩(wěn)定性上都會更完善，更適合在擁有C端用戶的產品上或者是擁有多個產品線的公司級項目中應用。

想要設計出一個能滿足企業(yè)級項目需求的用戶認證體系，我們需要從用戶體驗、安全和穩(wěn)定性上來考慮，同時也要收集產品經理、前端開發(fā)對其在功能性上的要求，不能為了只考慮穩(wěn)定、高效而忽略了用戶體驗。

從功能的用戶體驗、安全性和穩(wěn)定性來看，通常一個足夠支撐企業(yè)級項目的認證系統(tǒng)要滿足一下要求：

• 用戶體驗：

a.保證用戶登錄后，在較長時間內不需要重新登錄，比如15天或者30天內登錄過就不需要讓用戶再主動登錄。

b.支持多平臺登錄，用戶在App平臺上的登錄行為不會踢掉用戶在H5端的登錄狀態(tài)。

c.在同一平臺上，如果發(fā)生多設備登錄要能把老設備的登錄態(tài)踢掉。

• 安全性：
• 用戶認證用的Token不可偽造，除發(fā)放Token的服務端外無法自行生成Token。
• Token 具有較快的過期機制（1～2 h），減少被人獲取Token后偽裝成用戶進行操作的幾率。
• 能有發(fā)現機制，發(fā)現Token被竊取，或者客戶端存在舊Token未更新；
• 穩(wěn)定性：
• Token 具有自解釋性，即自帶某些信息，在某些極端惡劣情況下，依然能提供最基本的服務。

用戶認證體系的實現思路和方案

為什么所有商用項目都需要用戶認證體系呢？最簡單的一個原因是：因為用戶的ID不能外漏。在產品內部與用戶相關的數據資產都是使用用戶ID標記用戶歸屬的，一旦外漏造成的風險和損失不可預估。

在我們設計的認證體系中，用戶登錄后返回給前端以下Token信息。

為什么有兩個Token

主要考慮下面三個因素：

• 一個Token即負責認證又負責刷新，這種方式前端頁面會有并發(fā)請求的情況，Token 的刷新需要加鎖，會帶來很大的開銷；
• 無法保證前端刷新 Token 的互斥時，會出現Token反復失效的情況；
• 還有就是我們設計的refreshToken能幫助我們發(fā)現Token被盜和過期未更新的問題

Token信息的構成和存儲

服務端 Token 存儲的信息（服務端記錄的信息）如下：

用戶登錄授權，在給用戶發(fā)放Token的同時服務端會存儲三份信息，用于會話管理和認證。

圖片

它們存儲的主要信息和其存儲方式如下：

圖片

上面我們一直提到了用戶登錄平臺Platform、SessionId ，它們分別是什么呢？

• Platform：是我們自己定義的用戶登錄平臺，比如H5、App、Web 之類的，用戶登錄時需要在Header頭中攜帶約定的Platform值，用于標記用戶的不同登錄端。這個字段的設置是為了保證不同端的登錄和Token刷新相互之間不會受到影響，避免在App上刷新Token，導致H5 的用戶Token失效的問題。
• SessionId：會話ID，登錄后的唯一標識，Token刷新時不會改變會話ID，仍然設置為原SessionId，只有在用戶重新登錄后SessionId才會改變，項目可以使用它記錄一些與登錄行為關聯的數據。

Token驗證和刷新的流程

Token的驗證和刷新流程給大家準備了詳盡的UML活動圖和案例進行講解

圖片