轉自：http://www.primeton.com/read.php?id=2667&his=1
引言：
微服務大行其道，微服務安全也是非常熱門的話題。本文向大家分享微服務系統中認證管理相關技術。其中包括用戶認證、網關和 API 認證、系統間和系統內的認證，以及我們的統一認證管理系統 IAM。
目錄：
一、簡介
二、用戶認證
三、網關及API調用認證
四、系統間認證和系統內認證
五、總結
一、簡介
首先，我們來看一下什麼是認證？
認證是確認當前聲稱爲 xxx 的用戶確實爲 xxx 本身。
用戶可以是人、系統、應用或任意調用者。
最簡單的認證，就是用戶名密碼登錄，常見的認證方式還有：手機驗證碼、生物識別（指紋，虹膜識別、面部識別等）、U 盾、數字證書。
關於認證更加詳盡的定義和認證方式，請參見維基百科：https://en.wikipedia.org/wiki/Authentication
那在微服務系統中有哪些地方需要進行認證管理(不包括DevOps中的認證)呢？如下圖所示：
凡是存在交互的地方均需要進行認證：
用戶訪問系統
系統調用網關
網關調用系統
系統內應用之間的調用
系統間的調用
可以將它們分爲如下三類：
用戶認證
系統間及系統內認證
網關及 API 調用認證
下面我們將對這三類認證，分別做詳細的介紹。
二、用戶認證
微服務架構中會存在很多系統，而且系統間的切換也需要無縫進行，例如一個前端框架中可能會集成多個系統的調用。此時，我們自然而然的會想到單點登錄，單點登錄早在已存在。但微服務中的單點登錄與傳統的單點登錄有一定的差異。
下面這幅圖描述傳統的基於 Session 的單點登錄。
用戶的授權信息（例如角色，可訪問資源等）保存在應用的 session 中，瀏覽器與應用系統之間基於sessionID 關聯，相同應用的集羣使用緩存（如 Redis、memcached 等），或基於 session 複製來進行共享 session 信息。
但是微服務系統中，api 的調用都是 stateless，沒有狀態信息，如下圖所示：
用戶的授權信息通常直接封裝到 token 中，用戶在訪問應用或系統的時候，攜帶上 token，應用或系統直接從 token 中反解出用戶的授權相關信息
2.1.OAuth2.0與SSO
OAuth2.0是授權框架，SSO 是認證服務，但是我們可以基於 OAuth2.0實現SSO 認證服務。
OAuth2.0本身不提供認證服務，但是具有足夠的擴展空間，讓我們來擴展，例如基於 OAuth2.0 的OIDC。
2.2.基於OAuth2.0的單點登錄
上圖所示,爲一個基於OAuth2.0的 SSO的流程，整體流程基本上和普通的 SSO 一致，所不同的是，存儲 app Cookie 的時候，保存的是經過應用或系統處理和加密過的 token，用戶後續請求，帶上加密後的 token，在 app 後端直接解密和抽取出用戶相關的授權信息，流程如下:
1. 用戶訪問app1.com
2. 由於用戶沒有登錄，因此跳轉到 iam.com
3. 用戶在 iam.com的登錄頁面，輸入用戶名和密碼，確認提交，iam 校驗成功後
4. 在瀏覽器端寫入瀏覽器cookie
5. 重定向到 app1.com，並獲取 token(此處獲取 token流程，與OAuth2.0協議有關)
6.app1.com檢查 token 有效性
7. 重定向用戶訪問頁面，並存儲 app1.com的token 到app1.com的cookie 中
8. 用戶訪問app2.com
9.app2.com重定向到iam.com
10.iam.com此時發現 cookie 內已經有認證的token（或 session） 信息
11. 直接重定向到app2.com,並獲得 token 信息
12.app2.com驗證 token 信息
13. 重定向到app2.com,並保存app2.com的 token 信息到 app2.com 的 cookie 中
2.3.Token
通常情況下，IAM會使用類似jwt 這樣的協議去封裝用戶信息和授權相關信息。
App需要對 Token 進行處理，加密後再存入到瀏覽器 cookie 中去。
2.4.單點退出
傳統的 SLO 是由 SSO 服務器通知每一個應用系統，強制 session失效。
在微服務系統中，由於系統或應用間調用是無狀態的,因此 IAM 無法通知每個應用退出指定用戶。
但是，我們可以利用 OAuth2.0 的refreshToken 機制,當app去refreshToken的時候，通知應用退出。
首先，當一個應用點擊退出時，應用先通知 IAM 清除當前用戶在 IAM 上的session 和所有相關的認證 Token 信息。
當其他應用進行refreshToken的時候，返回用戶已經退出的信息，要求用戶重新登錄。
注意：這樣的單點退出不是實時的，會存在一個誤差（accessToken的有效時間）
2.5.用戶登錄控制
基於OAuth2.0 實現的 SSO，可以對用戶是否可以登錄某一系統進行控制。
在系統去交換/獲取 Token的時候，判斷用戶是否具有訪問指定系統的權限。
特點：可在線控制用戶訪問或拒絕訪問指定系統。
缺點：同樣不是實時的，會存在一個誤差（accessToken的有效時間）。
2.6.在線用戶管理
當用戶登錄IAM 的時候，IAM 可以跟蹤和控制用戶登錄的超時。
當用戶使用 SSO“登錄”一個應用或系統時，會記錄用戶的 Token 信息。這裏需要說明一下，用戶的同一賬號，有時候是可以同時在不通的機器上進行登錄的。
通過控制“用戶登錄和系統授權”信息，來強制當前用戶下線和統計在線用戶信息和登錄系統的信息。
三、網關及 API 調用認證
網關管理員
網關管理員訪問網關係統，屬於用戶認證，則可以使用用戶認證的方式來進行認證
API 調用
API調用認證可以綁定一組 API 到一個隨機的 Token，使用Token 來唯一標識其綁定的一組 API 的訪問權限，我們可以在系統中對這個 token 進行分配配額和 API 調用的限制；
注意：Token本身是不綁定調用者，所以，任何擁有 token 的應用都可以進行訪問。
網關調用系統
網關調用系統，可以按照系統間的調用進行處理，請參見隨後章節，系統間的調用。
四、系統間認證和系統內認證
系統間認證和系統內認證，實際上都是應用之間的調用，所不同的是，前者的應用是跨系統的，後者是在同一個系統內。
應用間的調用認證，可以對系統信息、應用信息、調用相關信息進行編碼（jwt） 加密（jwe）， 然後再通過http header的方式傳輸到下游系統或應用，下游系統或應用通過解密，獲得調用者的相關信息，對其進行認證處理。
五、總結
認證管理有很多不同的方式，上面我所說的是一些常見的處理手段，也是普元統一認證管理平臺IAM目前使用到的一些技術手段。
（IAM功能結構圖）
（IAM部署結構圖）
以上我們重點介紹了用戶管理、SSO、SLO、網關及 API 調用認證、系統間和系統內認證及相關的處理技術。
當然，認證管理還有很多其他的處理手段和相關協議，比如認證授權協議： OIDC、SAML等，這裏就不贅述了，有機會再和大家探討。
參考內容
https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/
https://searchsecurity.techtarget.com/definition/single-sign-on
https://en.wikipedia.org/wiki/Single_sign-on
https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/
https://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
https://blog.heroku.com/oauth-sso
https://mp.weixin.qq.com/s/x0CZpovseOuofTA_lw0HvA