一、概述
登陸和認證是什麼？都是在鑒别使用者的身份。如何鑒定識别出這是哪個使用者？或者說，有什麼方式隻有使用者自己知道（夠安全），又能說出這是他自己？于是就有了"使用者名+密碼"、"使用者名+手機号" 的方式出現。下面主要分析 “使用者名+密碼”的登陸鑒權方式：
- 出于安全考慮，我們不可能在所有的請求裡都使用“使用者名+密碼”。
- "使用者名+密碼"不能存儲在任何地方，最安全的方式就是存放在使用者自己的腦子裡，也就是說如果要使用 “使用者名+密碼” 就得讓使用者自己提供。
那麼我們如何做到可以不用提供使用者名和密碼呢？我們在使用者登入的時候，根據使用者的身份資訊去生成一種能标記使用者的 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 資訊擷取使用者資訊，然後帶着使用者資訊去請求業務資料