微服務統一登陸認證怎麼做?JWT?

無狀態登錄原理

什麼是有狀態?

有狀態服務,即服務端需要記錄每次會話的客戶端信息,從而識別客戶端身份,根據用戶身份進行請求的處理,典型的設計如tomcat中的session。

例如登錄:用戶登錄後,我們把登錄者的信息保存在服務端session中,並且給用戶一個cookie值,記錄對應的session。然後下次請求,用戶攜帶cookie值來,我們就能識別到對應session,從而找到用戶的信息。

缺點是什麼?

  • 服務端保存大量數據,增加服務端壓力
  • 服務端保存用戶狀態,無法進行水平擴展
  • 客戶端請求依賴服務端,多次請求必須訪問同一臺服務器


什麼是無狀態

微服務集群中的每個服務,對外提供的都是Rest風格的接口。而Rest風格的一個最重要的規範就是:服務的無狀態性,即:

  • 服務端不保存任何客戶端請求者信息
  • 客戶端的每次請求必須具備自描述信息,通過這些信息識別客戶端身份

帶來的好處是什麼呢?

  • 客戶端請求不依賴服務端的信息,任何多次請求不需要必須訪問到同一臺服務
  • 服務端的集群和狀態對客戶端透明
  • 服務端可以任意的遷移和伸縮
  • 減小服務端存儲壓力


如何實現無狀態

無狀態登錄的流程:

1. 當客戶端第一次請求服務時,服務端對用戶進行信息認證(登錄)

2. 認證通過,將用戶信息進行加密形成token,返回給客戶端,作為登錄憑證

3. 以後每次請求,客戶端都攜帶認證的token

4. 服務端對token進行解密,判斷是否有效。

流程圖:

微服務統一登陸認證怎麼做?JWT?

整個登錄過程中,最關鍵的點是什麼?

token的安全性

token是識別客戶端身份的唯一標示,如果加密不夠嚴密,被人偽造那就完蛋了。

採用何種方式加密才是安全可靠的呢?

我們將採用JWT + RSA非對稱加密


JWT

簡介

JWT,全稱是Json Web Token, 是JSON風格輕量級的授權和身份認證規範,可實現無狀態、分佈式的Web應用授權

官網:https://jwt.io

GitHub上jwt的java客戶端:https://github.com/jwtk/jjwt


數據格式

JWT包含三部分數據:

Header:頭部,通常頭部有兩部分信息:

  • 聲明類型,這裡是JWT
  • 加密算法,自定義

我們會對頭部進行base64加密(可解密),得到第一部分數據

Payload:載荷,就是有效數據,一般包含下面信息:

  • 用戶身份信息(注意,這裡因為採用base64加密,可解密,因此不要存放敏感信息)
  • 註冊聲明:如token的簽發時間,過期時間,簽發人等

這部分也會採用base64加密,得到第二部分數據

Signature:簽名,是整個數據的認證信息。一般根據前兩步的數據,再加上服務的密鑰(secret)(不要洩漏,最好週期性更換),通過加密算法生成。用於驗證整個數據完整和可靠性

生成的數據格式:

微服務統一登陸認證怎麼做?JWT?

可以看到分為3段,每段就是上面的一部分數據

JWT交互流程

流程圖:

微服務統一登陸認證怎麼做?JWT?

步驟翻譯:

  1. 用戶登錄
  2. 服務的認證,通過後根據secret生成token
  3. 將生成的token返回給瀏覽器
  4. 用戶每次請求攜帶token
  5. 服務端利用公鑰解讀jwt簽名,判斷簽名有效後,從Payload中獲取用戶信息
  6. 處理請求,返回響應結果

因為JWT簽發的token中已經包含了用戶的身份信息,並且每次請求都會攜帶,這樣服務的就無需保存用戶信息,甚至無需去數據庫查詢,完全符合了Rest的無狀態規範。


非對稱加密

加密技術是對信息進行編碼和解碼的技術,編碼是把原來可讀信息(又稱明文)譯成代碼形式(又稱密文),其逆過程就是解碼(解密),加密技術的要點是加密算法,加密算法可以分為三類:

對稱加密,如AES

  • 基本原理:
    將明文分成N個組,然後使用密鑰對各個組進行加密,形成各自的密文,最後把所有的分組密文進行合併,形成最終的密文。
  • 優勢:算法公開、計算量小、加密速度快、加密效率高
  • 缺陷:雙方都使用同樣密鑰,安全性得不到保證

非對稱加密,如RSA

  • 基本原理:同時生成兩把密鑰:私鑰和公鑰,私鑰隱秘保存,公鑰可以下發給信任客戶端
  • 私鑰加密,持有私鑰或公鑰才可以解密
  • 公鑰加密,持有私鑰才可解密
  • 優點:安全,難以破解
  • 缺點:算法比較耗時

不可逆加密,如MD5,SHA

  • 基本原理:加密過程中不需要使用密鑰,輸入明文後由系統直接經過加密算法處理成密文,這種加密後的數據是無法被解密的,無法根據密文推算出明文。

RSA算法歷史:

1977年,三位數學家Rivest、Shamir 和 Adleman 設計了一種算法,可以實現非對稱加密。這種算法用他們三個人的名字縮寫:RSA


結合Zuul的鑑權流程

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

沒有RSA加密時

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

微服務統一登陸認證怎麼做?JWT?

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

發現什麼問題了?

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


結合RSA的鑑權

直接看圖:

微服務統一登陸認證怎麼做?JWT?

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


分享到:


相關文章: