無狀態登錄原理 token - 微服務 Zuul + JWT + RSA

1.無狀態登錄原理

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

1.5.結合Zuul的鑑權流程

我們逐步演進系統架構設計。需要注意的是：secret是簽名的關鍵，因此一定要保密，我們放到鑑權中心保存，其它任何服務中都不能獲取secret。

1.5.1.沒有RSA加密時

在微服務架構中，我們可以把服務的鑑權操作放到網關中，將未通過鑑權的請求直接攔截，如圖：

• 1、用戶請求登錄
• 2、Zuul將請求轉發到授權中心，請求授權
• 3、授權中心校驗完成，頒發JWT憑證
• 4、客戶端請求其它功能，攜帶JWT
• 5、Zuul將jwt交給授權中心校驗，通過後放行
• 6、用戶請求到達微服務
• 7、微服務將jwt交給鑑權中心，鑑權同時解析用戶信息
• 8、鑑權中心返回用戶數據給微服務
• 9、微服務處理請求，返回響應

發現什麼問題了？

每次鑑權都需要訪問鑑權中心，系統間的網絡請求頻率過高，效率略差，鑑權中心的壓力較大。

1.5.2.結合RSA的鑑權

直接看圖：

• 我們首先利用RSA生成公鑰和私鑰。私鑰保存在授權中心，公鑰保存在Zuul和各個微服務
• 用戶請求登錄
• 授權中心校驗，通過後用私鑰對JWT進行簽名加密
• 返回jwt給用戶
• 用戶攜帶JWT訪問
• Zuul直接通過公鑰解密JWT，進行驗證，驗證通過則放行
• 請求到達微服務，微服務直接用公鑰解析JWT，獲取用戶信息，無需訪問授權中心