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