基於 Token 的用戶認證

用戶認證

用戶認證是互聯網服務中重要流程，決定了服務的安全性。生活中靠身份證，網絡上就要靠帳號和密碼。HTTP做爲一種無狀態協議，沒辦法記住用戶的登陸狀態。所以咱們須要藉助一些手段，來判斷用戶的登陸狀態，從而決定用戶是否具備操做權限。

用戶認證：

1. 傳統Session用戶認證
2. 基於Token的用戶認證

基於Session的用戶認證

早期互聯網使用Cookie(客戶端)和Session(服務端)來記錄和認證用戶信息。Session與Cookie均是用來記錄一系列狀態，的區別在於Session是記錄在服務端的，而Cookie是記錄在客戶端的。

認證流程：

1. 用戶向服務器發送用戶名和密碼。
2. 服務器驗證經過後，在當前對話（session）裏面保存相關數據，好比用戶角色、登陸時間等等。
3. 服務器向用戶返回一個 session_id，寫入用戶的 Cookie。
4. 用戶隨後的每一次請求，都會經過 Cookie，將 session_id 傳回服務器。
5. 服務器收到 session_id，找到前期保存的數據，由此得知用戶的身份。

缺點

1. Session 須要存在服務器內存中，這樣就不能跨實例共享。當下一次請求被分發到另外一個實例的時候，須要從新登陸。
2. 在高併發狀況下，Session 須要放在內存中，受限於服務器內存的大小。Token只須要在服務器進行解析驗證。
3. Session 依賴於瀏覽器的 Cookie 機制，對於部分軟件和移動客戶端很難支持。而Token不只在Web仍是移動端都有很好的支持。

由於種種限制，如今普遍使用的是基於Token的用戶認證。

基於Token的用戶認證

token 是登陸以後服務器返回的一段加密字符串（加密算法有多種），存儲到本地。在客戶端請求服務端數據的時候能夠帶上（放在請求頭headers，參數都行），如下只是思路。

認證流程

1. 當用戶登陸成功後，服務器端就會經過指定算法生成一個 token，將token 存放在 redis，再將這個 token 值返回給客戶端。
2. 客戶端將 token 存儲在 localstorage 或 sessionstorage中 (小程序能夠存放在 app.global )。
3. 當客戶端調用接口請求數據時，攜帶 token 值發送給服務器。
4. 服務器接收到客戶端的請求以後，會先解析返回的 token 獲得用戶信息驗證，並取出 token 值與保存在 redis 的token值作對比。
5. 若是token對比成功，說明用戶處於登陸狀態，不然表示登陸狀態失效，須要用戶從新登錄。用戶每次從新登錄會刷新token的過時時間。