預備知識
本文討論基於微服務架構下的身份認證和用戶授權的技術方案，最好先熟悉並理解以下幾個知識點：
-
微服務架構相關概念：服務註冊、服務發現、API 網關
-
身份認證和授權技術：SSO、CAS、OAuth2.0、JWT
以下幾個基礎概念：
- 認證
- 授權
- 鑑權
- 權限控制
前提背景
當企業的應用系統逐漸增多後，每個系統單獨管理各自的用戶數據容易行成信息孤島，分散的用戶管理模式阻礙了企業應用向平臺化演進。當企業的互聯網業務發展到一定規模，構建統一的標準化賬戶管理體系將是必不可少的，因爲它是企業互聯網雲平臺的重要基礎設施，能夠爲平臺帶來統一的帳號管理、身份認證、用戶授權等基礎能力，爲企業帶來諸如跨系統單點登錄、第三方授權登錄等基礎能力，爲構建開放平臺和業務生態提供了必要條件。
模式介紹
在微服務架構下，必須對企業的平臺生態進行合理的業務劃分，每個業務板塊將自成系統，這些系統業務比較獨立，應當獨立拆分。每個系統又可根據各自的業務模型進行切分，將業務模型和用戶需求統籌分析後建立恰當的領域模型，形成獨立的服務。
另外，企業平臺的客戶範圍比較複雜，有2B的業務，也有2C的，還有 2G（goverment）的，因此平臺級的統一身份管理必須涉及組織實體和個人實體兩類，其中組織實體包括機關（G）、企業單位（B）、團體組織（B）等，這類似於多租戶架構的概念，但又比傳統多租戶架構複雜。
微服務架構的登陸認證問題
從過去單體應用架構到分佈式應用架構再到現在的微服務架構，應用的安全訪問在不斷的經受考驗。爲了適應架構的變化、需求的變化，身份認證與鑑權方案也在不斷的更新變革。面對數十個甚至上百個微服務之間的調用，如何保證高效安全的身份認證？面對外部的服務訪問，該如何提供細粒度的鑑權方案？本文將會爲大家闡述微服務架構下的安全認證與鑑權方案。
統一身份管理（Unified Identity Manager）
統一身份管理（UIM）是整個平臺帳號和權限管控的基礎，由此構建的系統稱爲UIMS（Unified Identity Management System），平臺下所有系統的賬戶管理、身份認證、用戶授權、權限控制等行爲都經由 UIMS 處理，提供帳號密碼管理、基本資料管理、角色權限管理等功能。
UIMS 基於『統一身份治理』的概念，可劃分爲兩級賬戶體系、基礎權限模塊和基礎信息模塊三大模塊。其中兩級賬戶體系將賬戶分爲組織實體帳號和個人實體賬戶兩大類，個人實體從屬於組織實體，也可以不從屬任何組織實體，且個人實體可同時從屬於多個組織實體；基礎權限模塊將各業務系統的資源權限進行統一管理和授權；
基礎信息模塊用於描述組織實體和個人實體的基本信息，如組織實體名稱、地址、法人，個人實體姓名、電話號碼、性別等基礎信息。UIMS 提供統一的 API 與各子系統連接。衆多系統和衆多服務都將依賴於 UIMS 。
本文僅涉及 UIMS 下的兩級賬戶體系和基礎權限模塊這兩個模塊，據此可以獨立出賬戶管理服務和權限管理服務，也可以合併成一個賬戶權限管理服務。其中賬戶管理服務包括業務系統實體、組織實體和個人實體管理、權限管理服務包含認證、授權和鑑權三個部分。
單點登錄（SSO）
企業平臺涉及衆多子系統，爲簡化各子系統的用戶管理，提升用戶體驗，因此實現 SSO 是統一身份認證的重要目標：一次登錄，全部訪問。
- 對於企業內部應用來說，SSO 是必須的選項，例如企業 OA、HR、CRM 等內部系統；
- 對於外部應用來說，SSO 是可選項，具體哪個應用應當加入 SSO 系統，由該業務系統決定。
例如，外部商城、物業系統等對外服務系統。無論何種應用是否採用 SSO，UIMS 在技術上應當具備 SSO 的能力。
授權登錄
隨着平臺業務的逐漸增長，依託於平臺的，和平臺依託的廠商和客戶等資源將極大的豐富平臺，因此必須構築開放的生態系統，以支撐業務的進一步發展。可以開放平臺級的授權登錄功能，以允許第三方應用接入。通過三方授權登錄，將平臺的服務各能力開發給第三方，並將第三方的服務和能力接入平臺，繁榮共生，共同發展。
服務間鑑權
業務系統切分出不同的服務，根據粒度粗細和業務需求不同，服務的數量和權限要求都不同。微服務架構下的身份認證和授權，可分爲兩種：
-
內部服務的認證和授權；
- 內部服務處於安全的內網環境之下，例如 BFF 層（Backend For Frontend Layer）的商品服務、訂單服務等，在對安全需求不高的情況下，可不執行認證過程，服務與服務之間是相互信任的。
-
外部服務的認證和授權。
- 外部服務的認證和授權，通常由外部應用發起，通過反向代理或網關向安全邊界內的服務發起請求，因此必須執行嚴格的認證過程。無線端APP、Web端、桌面客戶端等外部應用下的各類服務，都屬於外部服務。
技術方案
備選方案
提出了統一身份管理系統（UIMS）下關於身份認證和授權部分的主要需求，目前實現統一身份認證和授權的技術手段較多，總體可以歸納爲以下兩類：
- 傳統的 Cookie + Session 解決方案，有狀態會話模式；
- 基於令牌/票ticket的解決方案，無狀態交互模式。
具體有
- 分佈式 Session
- OAuth2.0
- CAS
上述方案各有利弊：
分佈式 Session
分佈式Session是老牌的成熟解決方案，但因其狀態化通信的特性與微服務提倡的API導向無狀態通信相互違背，且共享式存儲存在安全隱患，因此微服務一般不太採用。
分佈式 Session
OAuth2.0是業內成熟的授權登錄解決方案，然而 OAuth2.0 提供了4種授權模式，能夠適應多種場景，作爲基於令牌的安全框架，可以廣泛用於需要統一身份認證和授權的場景。
一般會採用 JWT 作爲令牌的主要標準：JWT（JSON Web Token）是一種簡潔的自包含的 JSON 聲明規範，因其分散存儲和自解籤等特點而廣泛應用於非集中式認證/授權場景。
由於 JWT 信息是經過簽名的，可以確保發送方的真實性，確保信息未經篡改和僞造。但由於其自包含的客戶端驗籤特性，令牌一經簽發，即無法撤銷，因此單純採用 JWT 作爲統一身份認證和授權方案無法滿足帳號統一登出和銷燬、帳號封禁和解除這幾種類型的需求，所以一般配合 OAuth2.0 一起使用。
關於 JWT 的介紹，CAS 是時下最成熟的開源單點登錄方案，包含 CAS Server 和 CAS Client 兩部分。
- CAS Server 是一個 war 包需要獨立部署，負責用戶認證；
- CAS Client 負責處理對客戶端受保護資源的訪問請求，需要認證時，重定向到 CAS Server。
值得注意的是，CAS 是一個認證框架，其本身定義了一套靈活完整的認證流程，但其兼容主流的認證和授權協議如 OAuth2、SAML、OpenID 等，因此一般採用 CAS + OAuth2 的方案實現 SSO 和授權登錄。
關於 CAS 的介紹，請參考 https://apereo.github.io/cas/
在微服務架構下，身份認證和用戶授權通常分離出來成爲獨立的 IDP （Identity Provider）服務。在做技術選型時，應從以下幾點考慮：
- 滿足 SSO 的技術需求；
- 滿足簡便性和安全性的需求；
- 滿足開放性和擴展性的需求。
- 綜合考慮，推薦採用無狀態 API 模式，其中基於 OAuth2.0 的方案能夠完全滿足
客戶端 Token 方案
令牌在客戶端生成，由身份驗證服務進行簽名，並且必須包含足夠的信息，以便可以在所有微服務中建立用戶身份。令牌會附加到每個請求上，爲微服務提供用戶身份驗證，這種解決方案的安全性相對較好，但身份驗證註銷是一個大問題，緩解這種情況的方法可以使用短期令牌和頻繁檢查認證服務等。對於客戶端令牌的編碼方案，Borsos 更喜歡使用 JSON Web Tokens（JWT），它足夠簡單且庫支持程度也比較好。
客戶端 Token 與 API 網關結合
這個方案意味着所有請求都通過網關，從而有效地隱藏了微服務。 在請求時，網關將原始用戶令牌轉換爲內部會話 ID 令牌。在這種情況下，註銷就不是問題，因爲網關可以在註銷時撤銷用戶的令牌。