一、概述
登陸和認證是什么？都是在鑒別用戶的身份。如何鑒定識別出這是哪個用戶？或者說，有什么方式只有用戶自己知道（夠安全），又能說出這是他自己？於是就有了"用戶名+密碼"、"用戶名+手機號" 的方式出現。下面主要分析 “用戶名+密碼”的登陸鑒權方式：
- 出於安全考慮，我們不可能在所有的請求里都使用“用戶名+密碼”。
- "用戶名+密碼"不能存儲在任何地方，最安全的方式就是存放在用戶自己的腦子里，也就是說如果要使用 “用戶名+密碼” 就得讓用戶自己提供。
那么我們如何做到可以不用提供用戶名和密碼呢？我們在用戶登錄的時候，根據用戶的身份信息去生成一種能標記用戶的 token。
有了認證信息 token 以后，新的問題就是如何保證這個 token 是安全的呢？如果其他人拿到了這個 token 就能偽造用戶身份了。解決方案就是鑒定這個 token 是不是用戶本人在使用，一般我們通過以下方式，如果我們能保證下面的兩種驗證信息是一直都沒變或者在可接受的范圍內，我們就能認為這個用戶一直在使用我們下發的 token。
- 位置信息（ip、經緯度）
- 設備信息
現在我們已經做到了 token + （位置、設備信息）來鑒定用戶的身份。如果我們每次請求都要鑒定這些信息來確認用戶身份，勢必影響我們服務的性能。那么如何減少這樣的判定呢？
- 服務端隨機或者定時選定一次請求鑒定
- 客戶端定時請求一次鑒定
第一種方式不建議，服務器維護每個用戶定時復雜，隨機可能會有大量用戶同時鑒定的性能問題。那么就是第二種了，客戶端定時請求一次鑒定，服務端需要強制客戶端定時請求一次鑒定，而這個定時時間就是一個安全因素，如果在期間 token 泄露就會造成用戶信息安全問題，時間不能太長，也不能太短，參考微信的是 7200s 就是 2 小時。
那么如何強制客戶端每隔一段時間做一次驗證呢？很簡單，我們給 token 設個有效時間，到失效時間客戶端就必須請求一次新的 token，於是就有了 refresh token。
二、鑒權方式
用戶登錄后，每次請求服務時客戶端請求都要包含鑒權信息，服務端根據鑒權信息查詢用戶信息和其合法性。目前鑒權信息可以有如下方式：
1. 集中式 session 方式
在登陸完成后，服務端將返回作為認證鑒權的隨機不重復 token，客戶端每次請求帶上這個 token（一般放在請求的 header 里面）。服務端通過 token 查詢到 token 對應的用戶信息。
2. 令牌方式
登陸完成后，服務端根據用戶信息和其他安全因素加密生成一個安全令牌（也就是 JWTS，JSON Web Tokens），該令牌中包含了用戶的身份信息，在認證鑒權時只需驗證令牌的合法性即可，解密即可取到用戶信息。
3. 比較
| 鑒權方式 | 優點 | 不足 |
|---|---|---|
| 集中式 session 方式 | 1. 服務端維護用戶狀態，可以管理用戶狀態，沒有失效和用戶信息一致問題； 2. 安全性相對較高 | 1. 服務端維護 Session 狀態，根據 Token 獲取用戶信息需要極高的性能要求 |
| 令牌方式 | 1. 客戶端記錄用戶狀態，服務是無狀態的，沒有集中式的性能問題。 2. 業務解耦，鑒權邏輯相對簡單的多，令牌方式在技術實現性能和可靠性上也相對容易些 | 1. 令牌強制失效或者續簽問題，令牌強制失效或更新需要額外工作（比如封禁用戶） 2. 當用戶信息更新后，令牌里的用戶的同步問題 |
三、鑒權實現方案
1. 集中式 session 方式流程時序
- 客戶端在未登錄的狀態下請求業務服務，在網關沒有獲取到認證信息時直接返回 401，告知客戶端需要登錄。
- 客戶端使用“手機號+密碼”、“手機號+驗證碼”的方式請求登陸服務。
- 網關發現是登陸服務后，請求登陸認證服務。
- 登陸認證服務通過手機號碼查詢用戶信息，同時生成 token。
- 返回網關 token，網關將 token 返回給客戶端。
- 客戶端帶着 token 請求網關，網關將 token 傳給鑒權服務，鑒權服務通過 token 查詢用戶信息並返回給網關，網關將用戶信息轉給業務服務，完成接下來的業務流程。
2. 令牌方式流程時序
- 客戶端在未登錄的狀態下請求業務服務，在網關沒有獲取到認證信息時直接返回 401，告知客戶端需要登錄。
- 客戶端使用“手機號+密碼”、“手機號+驗證碼”的方式請求登陸服務。
- 網關發現是登陸服務后，請求登陸認證服務，同時生成 token（JWT信息），並將 token 返回給客戶端。
- 客戶端帶着 token 請求網關，網關根據 token（JWT信息）解密得到用戶信息，並將用戶信息轉給業務服務，完成接下來的業務流程。
四、鑒權技術方案
1. 集中式Session鑒權技術方案
集中式Session鑒權驗證用戶身份有如下的實現方式：
| 實現 | 說明 | 優點 | 缺點 |
|---|---|---|---|
| RPC調用 | 網關通過RPC調用鑒權服務，通過token獲取用戶信息 | 架構邏輯簡單，不需要額外工作 | 增加響應 RT |
| Redis 直讀 | 網關直接讀取鑒權服務的 Redis，驗證並獲取用戶信息 | 高性能 | 需要網關也集成鑒權驗證邏輯，並且維護 Redis 的配置 |
| Nginx Lua | 在 Nginx 里通過 lua 腳本實現鑒權邏輯 | 性能最好 | 1. 在網關之前，對簽名無效的請求也需要做鑒權驗證。 2. Nginx 改造，lua 開發成本 |
2. 令牌方式鑒權技術方案
令牌方式鑒權的實現就簡單的多， 網關直接解析 JWT 信息獲取用戶信息，然后帶着用戶信息去請求業務數據。