預備知識
本文讨論基于微服務架構下的身份認證和使用者授權的技術方案，最好先熟悉并了解以下幾個知識點：
- 微服務架構相關概念：服務注冊、服務發現、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是老牌的成熟解決方案，但因其狀态化通信的特性與微服務提倡的API導向無狀态通信互相違背，且共享式存儲存在安全隐患，是以微服務一般不太采用。
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 令牌。在這種情況下，登出就不是問題，因為網關可以在登出時撤銷使用者的令牌。
參考資料
https://www.jianshu.com/p/2571f6a4e192
極限就是為了超越而存在的