SpringCloud微服務(wù)下權(quán)限解決方案
作者：厚德載物
cnblogs.com/zhenghongxin/p/10006697.html
無狀態(tài)登錄原理
1.1. 什么是有狀態(tài)？
有狀態(tài)服務(wù)，即服務(wù)端需要記錄每次會話的客戶端信息，從而識別客戶端身份，根據(jù)用戶身份進行請求的處理，典型的設(shè)計如 tomcat 中的 session。
例如登錄：用戶登錄后，我們把登錄者的信息保存在服務(wù)端 session 中，并且給用戶一個 cookie 值，記錄對應(yīng)的 session。然后下次請求，用戶攜帶 cookie 值來，我們就能識別到對應(yīng) session，從而找到用戶的信息。
缺點是什么？
服務(wù)端保存大量數(shù)據(jù)，增加服務(wù)端壓力
服務(wù)端保存用戶狀態(tài)，無法進行水平擴展
客戶端請求依賴服務(wù)端，多次請求必須訪問同一臺服務(wù)器
1.2. 什么是無狀態(tài)
微服務(wù)集群中的每個服務(wù)，對外提供的都是 Rest 風格的接口。而 Rest 風格的一個最重要的規(guī)范就是：服務(wù)的無狀態(tài)性，即：
服務(wù)端不保存任何客戶端請求者信息
客戶端的每次請求必須具備自描述信息，通過這些信息識別客戶端身份
帶來的好處是什么呢？
客戶端請求不依賴服務(wù)端的信息，任何多次請求不需要必須訪問到同一臺服務(wù)
服務(wù)端的集群和狀態(tài)對客戶端透明
服務(wù)端可以任意的遷移和伸縮
減小服務(wù)端存儲壓力
1.3. 如何實現(xiàn)無狀態(tài)
無狀態(tài)登錄的流程：
當客戶端第一次請求服務(wù)時，服務(wù)端對用戶進行信息認證（登錄）
認證通過，將用戶信息進行加密形成 token，返回給客戶端，作為登錄憑證
以后每次請求，客戶端都攜帶認證的 token
服務(wù)端對 token 進行解密，判斷是否有效。
流程圖：
整個登錄過程中，最關(guān)鍵的點是什么？
token 的安全性
token 是識別客戶端身份的唯一標示，如果加密不夠嚴密，被人偽造那就完蛋了。
采用何種方式加密才是安全可靠的呢？
我們將采用JWT + RSA非對稱加密
1.4.JWT
1.4.1. 簡介
JWT，全稱是 Json Web Token， 是 JSON 風格輕量級的授權(quán)和身份認證規(guī)范，可實現(xiàn)無狀態(tài)、分布式的 Web 應(yīng)用授權(quán)；官網(wǎng)：https://jwt.io
GitHub 上 jwt 的 java 客戶端：https://github.com/jwtk/jjwt
1.4.2. 數(shù)據(jù)格式
JWT 包含三部分數(shù)據(jù)：
Header：頭部，通常頭部有兩部分信息：
我們會對頭部進行 base64 加密（可解密），得到第一部分數(shù)據(jù)
聲明類型，這里是 JWT
加密算法，自定義
Payload：載荷，就是有效數(shù)據(jù)，一般包含下面信息：
這部分也會采用 base64 加密，得到第二部分數(shù)據(jù)
用戶身份信息（注意，這里因為采用 base64 加密，可解密，因此不要存放敏感信息）
注冊聲明：如 token 的簽發(fā)時間，過期時間，簽發(fā)人等
Signature：簽名，是整個數(shù)據(jù)的認證信息。一般根據(jù)前兩步的數(shù)據(jù)，再加上服務(wù)的的密鑰（secret）（不要泄漏，最好周期性更換），通過加密算法生成。用于驗證整個數(shù)據(jù)完整和可靠性
生成的數(shù)據(jù)格式：
可以看到分為 3 段，每段就是上面的一部分數(shù)據(jù)
1.4.3.JWT 交互流程
流程圖：
步驟翻譯：
1、用戶登錄
2、服務(wù)的認證，通過后根據(jù) secret 生成 token
3、將生成的 token 返回給瀏覽器
4、用戶每次請求攜帶 token
5、服務(wù)端利用公鑰解讀 jwt 簽名，判斷簽名有效后，從 Payload 中獲取用戶信息
6、處理請求，返回響應(yīng)結(jié)果
因為 JWT 簽發(fā)的 token 中已經(jīng)包含了用戶的身份信息，并且每次請求都會攜帶，這樣服務(wù)的就無需保存用戶信息，甚至無需去數(shù)據(jù)庫查詢，完全符合了 Rest 的無狀態(tài)規(guī)范。
1.4.4. 非對稱加密
加密技術(shù)是對信息進行編碼和解碼的技術(shù)，編碼是把原來可讀信息（又稱明文）譯成代碼形式（又稱密文），其逆過程就是解碼（解密），加密技術(shù)的要點是加密算法，加密算法可以分為三類：
對稱加密，如 AES
基本原理：將明文分成 N 個組，然后使用密鑰對各個組進行加密，形成各自的密文，最后把所有的分組密文進行合并，形成最終的密文。
優(yōu)勢：算法公開、計算量小、加密速度快、加密效率高
缺陷：雙方都使用同樣密鑰，安全性得不到保證
非對稱加密，如 RSA
基本原理：同時生成兩把密鑰：私鑰和公鑰，私鑰隱秘保存，公鑰可以下發(fā)給信任客戶端
私鑰加密，持有私鑰或公鑰才可以解密
公鑰加密，持有私鑰才可解密
優(yōu)點：安全，難以破解
缺點：算法比較耗時
不可逆加密，如 MD5，SHA
基本原理：加密過程中不需要使用密鑰，輸入明文后由系統(tǒng)直接經(jīng)過加密算法處理成密文，這種加密后的數(shù)據(jù)是無法被解密的，無法根據(jù)密文推算出明文。
RSA 算法歷史：
1977 年，三位數(shù)學家 Rivest、Shamir 和 Adleman 設(shè)計了一種算法，可以實現(xiàn)非對稱加密。這種算法用他們?nèi)齻€人的名字縮寫：RSA
結(jié)合 Zuul 的鑒權(quán)流程
我們逐步演進系統(tǒng)架構(gòu)設(shè)計。需要注意的是：secret 是簽名的關(guān)鍵，因此一定要保密，我們放到鑒權(quán)中心保存，其它任何服務(wù)中都不能獲取 secret。
1.5.1. 沒有 RSA 加密時
在微服務(wù)架構(gòu)中，我們可以把服務(wù)的鑒權(quán)操作放到網(wǎng)關(guān)中，將未通過鑒權(quán)的請求直接攔截，如圖：
1、用戶請求登錄
2、Zuul 將請求轉(zhuǎn)發(fā)到授權(quán)中心，請求授權(quán)
3、授權(quán)中心校驗完成，頒發(fā) JWT 憑證
4、客戶端請求其它功能，攜帶 JWT
5、Zuul 將 jwt 交給授權(quán)中心校驗，通過后放行
6、用戶請求到達微服務(wù)
7、微服務(wù)將 jwt 交給鑒權(quán)中心，鑒權(quán)同時解析用戶信息
8、鑒權(quán)中心返回用戶數(shù)據(jù)給微服務(wù)
9、微服務(wù)處理請求，返回響應(yīng)
發(fā)現(xiàn)什么問題了？
每次鑒權(quán)都需要訪問鑒權(quán)中心，系統(tǒng)間的網(wǎng)絡(luò)請求頻率過高，效率略差，鑒權(quán)中心的壓力較大。
結(jié)合 RSA 的鑒權(quán)
直接看圖：
我們首先利用 RSA 生成公鑰和私鑰。私鑰保存在授權(quán)中心，公鑰保存在 Zuul 和各個微服務(wù)
用戶請求登錄
授權(quán)中心校驗，通過后用私鑰對 JWT 進行簽名加密
返回 jwt 給用戶
用戶攜帶 JWT 訪問
Zuul 直接通過公鑰解密 JWT，進行驗證，驗證通過則放行
請求到達微服務(wù)，微服務(wù)直接用公鑰解析 JWT，獲取用戶信息，無需訪問授權(quán)中心
好文章，我在看