引言：

微服務大行其道，微服務安全也是非常熱門的話題。本文向大家分享微服務系統中認證管理相關技術。其中包括使用者認證、閘道器和 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