[發明專利]一種微服務架構服務間鑒權系統及優化方法

有效

• 申請號: 201810814095.9
• 申請日: 2018-07-23
• 公開（公告）號: CN108810029B
• 公開（公告）日: 2021-08-31
• 發明（設計）人: 羅奔
• 申請（專利權）人: 宏橋高科技集團有限公司
• 主分類號: H04L29/06
• 分類號: H04L29/06;H04L9/32
• 代理公司: 成都頂峰專利事務所(普通合伙) 51224
• 代理人: 王霞

本發明屬于微服務架構技術領域，公開了一種微服務架構服務間鑒權系統及優化方法，所述系統包括客戶端，發送具有Token請求頭的服務請求，接受加密后的Token并將該加密后的Token增加至請求頭，發送具有加密有的Token請求頭的服務請求，接受處理結果和新的Token；認證服務端，接收客戶端發出的具有Token請求頭的服務請求，并根據該Token采用私鑰加密生成加密后的Token，并返回加密后的Token；服務端，采用公鑰驗證具有加密后的Token請求頭的加密后的Token的簽名，更新該加密后的Token的有效時間，用私鑰加密生成新的Token，發出處理結果和新的Token。

技術領域

本發明屬于微服務架構技術領域，具體涉及一種微服務架構服務間鑒權系統及優化方法。

背景技術

隨著微服務架構的興起，傳統的單體應用場景下的身份認證和鑒權面臨的挑戰越來越大。單體應用體系下，應用是一個整體，一般針對所有的請求都會進行權限校驗。請求一般會通過一個權限的攔截器進行權限的校驗，在登錄時將用戶信息緩存到會話(session)中，后續訪問則從緩存中獲取用戶信息。

而微服務架構下，一個應用會被拆分成若干個微應用，每個微應用都需要對訪問進行鑒權，每個微應用都需要明確當前訪問用戶以及其權限。尤其當訪問來源不只是瀏覽器，還包括其他服務的調用時，單體應用架構下的鑒權方式就不是特別合適了。在微服務架構下，要考慮外部應用接入的場景、用戶-服務的鑒權、服務-服務的鑒權等多種鑒權場景。

隨著Restful API微服務的興起，基于令牌(Token)的認證現在已經越來越普遍。Token和Session ID不同，并非只是一個key。Token一般會包含用戶的相關信息，通過驗證Token就可以完成身份校驗。像Twitter、微信、QQ、GitHub等公有服務的API都是基于這種方式進行認證的，一些開發框架如OpenStack、Kubernetes內部API調用也是基于Token的認證。基于Token認證的一個典型流程如圖1所示。具體地，用戶輸入登錄信息(或者調用Token接口，傳入用戶信息)，發送到身份認證服務進行認證(身份認證服務可以和服務端在一起，也可以分離，看微服務拆分情況了)。身份驗證服務驗證登錄信息是否正確，返回接口(一般接口中會包含用戶基礎信息、權限范圍、有效時間等信息)，客戶端存儲接口，可以存儲在Session或者數據庫中。用戶將Token放在HTTP請求頭中，發起相關API調用。被調用的微服務，驗證Token權限。服務端返回相關資源和數據。

目前的上述處理方式針對Token的處理普遍采用對稱加密的算法處理。對稱加密算法的缺點是在數據傳送前，發送方和接收方必須商定好秘鑰，然后使雙方都能保存好秘鑰。其次如果一方的秘鑰被泄露，那么加密信息也就不安全了。另外，每對用戶每次使用對稱加密算法時，都需要使用其他人不知道的唯一秘鑰，這會使得收發雙方所擁有的鑰匙數量巨大，密鑰管理成為雙方的負擔。由于Token不存儲在服務端，由客戶端存儲，當用戶注銷時，Token的有效時間還沒有到，還是有效的，從而造成安全隱患。

發明內容

為了解決現有技術存在的上述問題，本發明目的在于提供一種微服務架構服務間鑒權系統及優化方法。

本發明所采用的技術方案為：

一種微服務架構服務間鑒權系統，包括：

客戶端，發送具有Token請求頭的服務請求，接受加密后的Token并將該加密后的Token增加至請求頭，發送具有加密有的Token請求頭的服務請求，接受處理結果和新的Token；

認證服務端，接收客戶端發出的具有Token請求頭的服務請求，并根據該Token采用私鑰加密生成加密后的Token，并返回加密后的Token；

服務端，采用公鑰驗證具有加密后的Token請求頭的加密后的Token的簽名，更新該加密后的Token的有效時間，用私鑰加密生成新的Token,發出處理結果和新的Token。