深入聊聊微服務(wù)架構(gòu)的身份認(rèn)證問題

從單體應(yīng)用架構(gòu)到分布式應(yīng)用架構(gòu)再到微服務(wù)架構(gòu)，應(yīng)用的安全訪問在不斷的經(jīng)受考驗(yàn)。為了適應(yīng)架構(gòu)的變化、需求的變化，身份認(rèn)證與鑒權(quán)方案也在不斷的變革。面對數(shù)十個(gè)甚至上百個(gè)微服務(wù)之間的調(diào)用，如何保證高效安全的身份認(rèn)證？面對外部的服務(wù)訪問，該如何提供細(xì)粒度的鑒權(quán)方案？本文將會為大家闡述微服務(wù)架構(gòu)下的安全認(rèn)證與鑒權(quán)方案。

??????????????????????????????????????????????????????????????????????????????????? 單體應(yīng)用 VS 微服務(wù)

隨著微服務(wù)架構(gòu)的興起，傳統(tǒng)的單體應(yīng)用場景下的身份認(rèn)證和鑒權(quán)面臨的挑戰(zhàn)越來越大。單體應(yīng)用體系下，應(yīng)用是一個(gè)整體，一般針對所有的請求都會進(jìn)行權(quán)限校驗(yàn)。請求一般會通過一個(gè)權(quán)限的攔截器進(jìn)行權(quán)限的校驗(yàn)，在登錄時(shí)將用戶信息緩存到 session 中，后續(xù)訪問則從緩存中獲取用戶信息。

而微服務(wù)架構(gòu)下，一個(gè)應(yīng)用會被拆分成若干個(gè)微應(yīng)用，每個(gè)微應(yīng)用都需要對訪問進(jìn)行鑒權(quán)，每個(gè)微應(yīng)用都需要明確當(dāng)前訪問用戶以及其權(quán)限。尤其當(dāng)訪問來源不只是瀏覽器，還包括其他服務(wù)的調(diào)用時(shí)，單體應(yīng)用架構(gòu)下的鑒權(quán)方式就不是特別合適了。在為服務(wù)架構(gòu)下，要考慮外部應(yīng)用接入的場景、用戶 - 服務(wù)的鑒權(quán)、服務(wù) - 服務(wù)的鑒權(quán)等多種鑒權(quán)場景。

David Borsos 在倫敦的微服務(wù)大會上提出了四種方案：

1. 單點(diǎn)登錄（SSO）

這種方案意味著每個(gè)面向用戶的服務(wù)都必須與認(rèn)證服務(wù)交互，這會產(chǎn)生大量非常瑣碎的網(wǎng)絡(luò)流量和重復(fù)的工作，當(dāng)動輒數(shù)十個(gè)微應(yīng)用時(shí)，這種方案的弊端會更加明顯。

2. 分布式 Session 方案

分布式會話方案原理主要是將關(guān)于用戶認(rèn)證的信息存儲在共享存儲中，且通常由用戶會話作為 key 來實(shí)現(xiàn)的簡單分布式哈希映射。當(dāng)用戶訪問微服務(wù)時(shí)，用戶數(shù)據(jù)可以從共享存儲中獲取。在某些場景下，這種方案很不錯，用戶登錄狀態(tài)是不透明的。同時(shí)也是一個(gè)高可用且可擴(kuò)展的解決方案。這種方案的缺點(diǎn)在于共享存儲需要一定保護(hù)機(jī)制，因此需要通過安全鏈接來訪問，這時(shí)解決方案的實(shí)現(xiàn)就通常具有相當(dāng)高的復(fù)雜性了。

3. 客戶端 Token 方案

令牌在客戶端生成，由身份驗(yàn)證服務(wù)進(jìn)行簽名，并且必須包含足夠的信息，以便可以在所有微服務(wù)中建立用戶身份。令牌會附加到每個(gè)請求上，為微服務(wù)提供用戶身份驗(yàn)證，這種解決方案的安全性相對較好，但身份驗(yàn)證注銷是一個(gè)大問題，緩解這種情況的方法可以使用短期令牌和頻繁檢查認(rèn)證服務(wù)等。對于客戶端令牌的編碼方案，Borsos 更喜歡使用 JSON Web Tokens（JWT），它足夠簡單且?guī)熘С殖潭纫脖容^好。

4. 客戶端 Token 與 API 網(wǎng)關(guān)結(jié)合

這個(gè)方案意味著所有請求都通過網(wǎng)關(guān)，從而有效地隱藏了微服務(wù)。 在請求時(shí)，網(wǎng)關(guān)將原始用戶令牌轉(zhuǎn)換為內(nèi)部會話 ID 令牌。在這種情況下，注銷就不是問題，因?yàn)榫W(wǎng)關(guān)可以在注銷時(shí)撤銷用戶的令牌。
微服務(wù)常見安全認(rèn)證方案
HTTP 基本認(rèn)證

HTTP Basic Authentication（HTTP 基本認(rèn)證）是 HTTP 1.0 提出的一種認(rèn)證機(jī)制，這個(gè)想必大家都很熟悉了，我不再贅述。HTTP 基本認(rèn)證的過程如下：

??? 客戶端發(fā)送 HTTP Request 給服務(wù)器。

??? 因?yàn)?Request 中沒有包含 Authorization header，服務(wù)器會返回一個(gè) 401 Unauthozied 給客戶端，并且在 Response 的 Header "WWW-Authenticate" 中添加信息。

??? 客戶端把用戶名和密碼用 BASE64 加密后，放在 Authorization Header 中發(fā)送給服務(wù)器， 認(rèn)證成功。

??? 服務(wù)器將 Authorization Header 中的用戶名密碼取出，進(jìn)行驗(yàn)證， 如果驗(yàn)證通過，將根據(jù)請求，發(fā)送資源給客戶端。

基于 Session 的認(rèn)證

基于 Session 的認(rèn)證應(yīng)該是最常用的一種認(rèn)證機(jī)制了。用戶登錄認(rèn)證成功后，將用戶相關(guān)數(shù)據(jù)存儲到 Session 中，單體應(yīng)用架構(gòu)中，默認(rèn) Session 會存儲在應(yīng)用服務(wù)器中，并且將 Session ID 返回到客戶端，存儲在瀏覽器的 Cookie 中。

但是在分布式架構(gòu)下，Session 存放于某個(gè)具體的應(yīng)用服務(wù)器中自然就無法滿足使用了，簡單的可以通過 Session 復(fù)制或者 Session 粘制的方案來解決。

Session 復(fù)制依賴于應(yīng)用服務(wù)器，需要應(yīng)用服務(wù)器有 Session 復(fù)制能力，不過現(xiàn)在大部分應(yīng)用服務(wù)器如 Tomcat、JBoss、WebSphere 等都已經(jīng)提供了這個(gè)能力。

除此之外，Session 復(fù)制的一大缺陷在于當(dāng)節(jié)點(diǎn)數(shù)比較多時(shí)，大量的 Session 數(shù)據(jù)復(fù)制會占用較多網(wǎng)絡(luò)資源。Session 粘滯是通過負(fù)載均衡器，將統(tǒng)一用戶的請求都分發(fā)到固定的服務(wù)器節(jié)點(diǎn)上，這樣就保證了對某一用戶而言，Session 數(shù)據(jù)始終是正確的。不過這種方案依賴于負(fù)載均衡器，并且只能滿足水平擴(kuò)展的集群場景，無法滿足應(yīng)用分割后的分布式場景。

在微服務(wù)架構(gòu)下，每個(gè)微服務(wù)拆分的粒度會很細(xì)，并且不只有用戶和微服務(wù)打交道，更多還有微服務(wù)間的調(diào)用。這個(gè)時(shí)候上述兩個(gè)方案都無法滿足，就要求必須要將 Session 從應(yīng)用服務(wù)器中剝離出來，存放在外部進(jìn)行集中管理。可以是數(shù)據(jù)庫，也可以是分布式緩存，如 Memchached、Redis 等。這正是 David Borsos 建議的第二種方案，分布式 Session 方案。

基于 Token 的認(rèn)證

隨著 Restful API、微服務(wù)的興起，基于 Token 的認(rèn)證現(xiàn)在已經(jīng)越來越普遍。Token 和 Session ID 不同，并非只是一個(gè) key。Token 一般會包含用戶的相關(guān)信息，通過驗(yàn)證 Token 就可以完成身份校驗(yàn)。像 Twitter、微信、QQ、GitHub 等公有服務(wù)的 API 都是基于這種方式進(jìn)行認(rèn)證的，一些開發(fā)框架如 OpenStack、Kubernetes 內(nèi)部 API 調(diào)用也是基于 Token 的認(rèn)證。基于 Token 認(rèn)證的一個(gè)典型流程如下：

??? 用戶輸入登錄信息（或者調(diào)用 Token 接口，傳入用戶信息），發(fā)送到身份認(rèn)證服務(wù)進(jìn)行認(rèn)證（身份認(rèn)證服務(wù)可以和服務(wù)端在一起，也可以分離，看微服務(wù)拆分情況了）。

??? 身份驗(yàn)證服務(wù)驗(yàn)證登錄信息是否正確，返回接口（一般接口中會包含用戶基礎(chǔ)信息、權(quán)限范圍、有效時(shí)間等信息），客戶端存儲接口，可以存儲在 Session 或者數(shù)據(jù)庫中。

??? 用戶將 Token 放在 HTTP 請求頭中，發(fā)起相關(guān) API 調(diào)用。

??? 被調(diào)用的微服務(wù)，驗(yàn)證 Token 權(quán)限。

??? 服務(wù)端返回相關(guān)資源和數(shù)據(jù)。

基于 Token 認(rèn)證的好處如下：

??? 服務(wù)端無狀態(tài)：Token 機(jī)制在服務(wù)端不需要存儲 session 信息，因?yàn)?Token 自身包含了所有用戶的相關(guān)信息。

??? 性能較好，因?yàn)樵隍?yàn)證 Token 時(shí)不用再去訪問數(shù)據(jù)庫或者遠(yuǎn)程服務(wù)進(jìn)行權(quán)限校驗(yàn)，自然可以提升不少性能。

??? 支持移動設(shè)備。

??? 支持跨程序調(diào)用，Cookie 是不允許垮域訪問的，而 Token 則不存在這個(gè)問題。

下面會重點(diǎn)介紹兩種基于 Token 的認(rèn)證方案 JWT/Oauth2.0。
JWT 介紹

JSON Web Token（JWT）是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于 JSON 的開放標(biāo)準(zhǔn)（RFC 7519）。來自 JWT RFC 7519 標(biāo)準(zhǔn)化的摘要說明：JSON Web Token 是一種緊湊的，URL 安全的方式，表示要在雙方之間傳輸?shù)穆暶?。JWT 一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該 Token 也可直接被用于認(rèn)證，也可被加密。
JWT 認(rèn)證流程

??? 客戶端調(diào)用登錄接口（或者獲取 token 接口），傳入用戶名密碼。

??? 服務(wù)端請求身份認(rèn)證中心，確認(rèn)用戶名密碼正確。

??? 服務(wù)端創(chuàng)建 JWT，返回給客戶端。

??? 客戶端拿到 JWT，進(jìn)行存儲（可以存儲在緩存中，也可以存儲在數(shù)據(jù)庫中，如果是瀏覽器，可以存儲在 Cookie 中）在后續(xù)請求中，在 HTTP 請求頭中加上 JWT。

??? 服務(wù)端校驗(yàn) JWT，校驗(yàn)通過后，返回相關(guān)資源和數(shù)據(jù)。

JWT 結(jié)構(gòu)

JWT 是由三段信息構(gòu)成的，第一段為頭部（Header），第二段為載荷（Payload)，第三段為簽名（Signature）。每一段內(nèi)容都是一個(gè) JSON 對象，將每一段 JSON 對象采用 BASE64 編碼，將編碼后的內(nèi)容用. 鏈接一起就構(gòu)成了 JWT 字符串。如下：

header.payload.signature

1. 頭部（Header）

頭部用于描述關(guān)于該 JWT 的最基本的信息，例如其類型以及簽名所用的算法等。這也可以被表示成一個(gè) JSON 對象。

{
"typ": "JWT",
"alg": "HS256"
}

在頭部指明了簽名算法是 HS256 算法。

2. 載荷（payload）

載荷就是存放有效信息的地方。有效信息包含三個(gè)部分：

??? 標(biāo)準(zhǔn)中注冊的聲明

??? 公共的聲明

??? 私有的聲明

標(biāo)準(zhǔn)中注冊的聲明（建議但不強(qiáng)制使用）：

??? iss：JWT 簽發(fā)者

??? sub：JWT 所面向的用戶

??? aud：接收 JWT 的一方

??? exp：JWT 的過期時(shí)間，這個(gè)過期時(shí)間必須要大于簽發(fā)時(shí)間

??? nbf：定義在什么時(shí)間之前，該 JWT 都是不可用的

??? iat：JWT 的簽發(fā)時(shí)間

??? jti：JWT 的唯一身份標(biāo)識，主要用來作為一次性 token, 從而回避重放攻擊。

公共的聲明 ：

公共的聲明可以添加任何的信息，一般添加用戶的相關(guān)信息或其他業(yè)務(wù)需要的必要信息. 但不建議添加敏感信息，因?yàn)樵摬糠衷诳蛻舳丝山饷堋?br />
私有的聲明 ：

私有聲明是提供者和消費(fèi)者所共同定義的聲明，一般不建議存放敏感信息，因?yàn)?base64 是對稱解密的，意味著該部分信息可以歸類為明文信息。

示例如下：

{ "iss": "Online JWT Builder",
?"iat": 1416797419,
?"exp": 1448333419,
?"aud": "www.primeton.com",
?"sub": "devops@primeton.com",
?"GivenName": "dragon",
?"Surname": "wang",
?"admin": true
}

3. 簽名（signature)

創(chuàng)建簽名需要使用 Base64 編碼后的 header 和 payload 以及一個(gè)秘鑰。將 base64 加密后的 header 和 base64 加密后的 payload 使用. 連接組成的字符串，通過 header 中聲明的加密方式進(jìn)行加鹽 secret 組合加密，然后就構(gòu)成了 jwt 的第三部分。

比如：HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

JWT 的優(yōu)點(diǎn)：

??? 跨語言，JSON 的格式保證了跨語言的支撐

??? 基于 Token，無狀態(tài)

??? 占用字節(jié)小，便于傳輸

關(guān)于 Token 注銷：

Token 的注銷，由于 Token 不存儲在服務(wù)端，由客戶端存儲，當(dāng)用戶注銷時(shí)，Token 的有效時(shí)間還沒有到，還是有效的。所以如何在用戶注銷登錄時(shí)讓 Token 注銷是一個(gè)要關(guān)注的點(diǎn)。一般有如下幾種方式：

??? Token 存儲在 Cookie 中，這樣客戶端注銷時(shí)，自然可以清空掉

??? 注銷時(shí)，將 Token 存放到分布式緩存中，每次校驗(yàn) Token 時(shí)區(qū)檢查下該 Token 是否已注銷。不過這樣也就失去了快速校驗(yàn) Token 的優(yōu)點(diǎn)。

??? 多采用短期令牌，比如令牌有效期是 20 分鐘，這樣可以一定程度上降低注銷后 Token 可用性的風(fēng)險(xiǎn)。

OAuth 2.0 介紹

OAuth 的官網(wǎng)介紹：An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications。OAuth 是一種開放的協(xié)議，為桌面程序或者基于 BS 的 web 應(yīng)用提供了一種簡單的，標(biāo)準(zhǔn)的方式去訪問需要用戶授權(quán)的 API 服務(wù)。OAUTH 認(rèn)證授權(quán)具有以下特點(diǎn)：

??? 簡單：不管是 OAuth 服務(wù)提供者還是應(yīng)用開發(fā)者，都很容易于理解與使用；

??? 安全：沒有涉及到用戶密鑰等信息，更安全更靈活；

??? 開放：任何服務(wù)提供商都可以實(shí)現(xiàn) OAuth，任何軟件開發(fā)商都可以使用 OAuth；

OAuth 2.0 是 OAuth 協(xié)議的下一版本，但不向后兼容 OAuth 1.0，即完全廢止了 OAuth 1.0。 OAuth 2.0 關(guān)注客戶端開發(fā)者的簡易性。要么通過組織在資源擁有者和 HTTP 服務(wù)商之間的被批準(zhǔn)的交互動作代表用戶，要么允許第三方應(yīng)用代表用戶獲得訪問的權(quán)限。同時(shí)為 Web 應(yīng)用，桌面應(yīng)用和手機(jī)，和起居室設(shè)備提供專門的認(rèn)證流程。2012 年 10 月，OAuth 2.0 協(xié)議正式發(fā)布為 RFC 6749。
授權(quán)流程

OAuth 2.0 的流程如下：

（A）用戶打開客戶端以后，客戶端要求用戶給予授權(quán)。（B）用戶同意給予客戶端授權(quán)。（C）客戶端使用上一步獲得的授權(quán)，向認(rèn)證服務(wù)器申請令牌。（D）認(rèn)證服務(wù)器對客戶端進(jìn)行認(rèn)證以后，確認(rèn)無誤，同意發(fā)放令牌。（E）客戶端使用令牌，向資源服務(wù)器申請獲取資源。（F）資源服務(wù)器確認(rèn)令牌無誤，同意向客戶端開放資源。
四大角色

由授權(quán)流程圖中可以看到 OAuth 2.0 有四個(gè)角色：客戶端、資源擁有者、資源服務(wù)器、授權(quán)服務(wù)器。

??? 客戶端：客戶端是代表資源所有者對資源服務(wù)器發(fā)出訪問受保護(hù)資源請求的應(yīng)用程序。

??? 資源擁有者：資源擁有者是對資源具有授權(quán)能力的人。

??? 資源服務(wù)器：資源所在的服務(wù)器。

??? 授權(quán)服務(wù)器：為客戶端應(yīng)用程序提供不同的 Token，可以和資源服務(wù)器在統(tǒng)一服務(wù)器上，也可以獨(dú)立出去。

客戶端的授權(quán)模式

客戶端必須得到用戶的授權(quán)（Authorization Grant），才能獲得令牌（access token）。OAuth 2.0 定義了四種授權(quán)方式：authorizationcode、implicit、resource owner password credentials、client credentials。

1. 授權(quán)碼模式（authorization code）

授權(quán)碼模式（authorization code）是功能最完整、流程最嚴(yán)密的授權(quán)模式。它的特點(diǎn)就是通過客戶端的后臺服務(wù)器，與"服務(wù)提供商"的認(rèn)證服務(wù)器進(jìn)行互動。流程如下：

??? 用戶訪問客戶端，后者將前者導(dǎo)向認(rèn)證服務(wù)器。

??? 用戶選擇是否給予客戶端授權(quán)。

??? 假設(shè)用戶給予授權(quán)，認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端事先指定的"重定向 URI"（redirection URI），同時(shí)附上一個(gè)授權(quán)碼。

??? 客戶端收到授權(quán)碼，附上早先的"重定向 URI"，向認(rèn)證服務(wù)器申請令牌。這一步是在客戶端的后臺的服務(wù)器上完成的，對用戶不可見。

??? 認(rèn)證服務(wù)器核對了授權(quán)碼和重定向 URI，確認(rèn)無誤后，向客戶端發(fā)送訪問令牌（access token）和更新令牌（refresh token）。

2. 簡化模式（implicit）

簡化模式（Implicit Grant Type）不通過第三方應(yīng)用程序的服務(wù)器，直接在瀏覽器中向認(rèn)證服務(wù)器申請令牌，跳過了"授權(quán)碼"這個(gè)步驟，因此得名。所有步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不需要認(rèn)證。流程如下：

??? 客戶端將用戶導(dǎo)向認(rèn)證服務(wù)器。

??? 用戶決定是否給于客戶端授權(quán)。

??? 假設(shè)用戶給予授權(quán)，認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端指定的"重定向 URI"，并在 URI 的 Hash 部分包含了訪問令牌。

??? 瀏覽器向資源服務(wù)器發(fā)出請求，其中不包括上一步收到的 Hash 值。

??? 資源服務(wù)器返回一個(gè)網(wǎng)頁，其中包含的代碼可以獲取 Hash 值中的令牌。

??? 瀏覽器執(zhí)行上一步獲得的腳本，提取出令牌。

??? 瀏覽器將令牌發(fā)給客戶端。

3. 密碼模式（Resource Owner Password Credentials）

密碼模式中，用戶向客戶端提供自己的用戶名和密碼?？蛻舳耸褂眠@些信息，向"服務(wù)商提供商"索要授權(quán)。在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲存密碼。這通常用在用戶對客戶端高度信任的情況下，比如客戶端是操作系統(tǒng)的一部分，或者由一個(gè)著名公司出品。而認(rèn)證服務(wù)器只有在其他授權(quán)模式無法執(zhí)行的情況下，才能考慮使用這種模式。流程如下：

??? 用戶向客戶端提供用戶名和密碼。

??? 客戶端將用戶名和密碼發(fā)給認(rèn)證服務(wù)器，向后者請求令牌。

??? 認(rèn)證服務(wù)器確認(rèn)無誤后，向客戶端提供訪問令牌。

4. 客戶端模式（Client Credentials）

客戶端模式（Client Credentials Grant）指客戶端以自己的名義，而不是以用戶的名義，向"服務(wù)提供商"進(jìn)行認(rèn)證。嚴(yán)格地說，客戶端模式并不屬于 OAuth 框架所要解決的問題。

在這種模式中，用戶直接向客戶端注冊，客戶端以自己的名義要求"服務(wù)提供商"提供服務(wù)，其實(shí)不存在授權(quán)問題。流程如下：

??? 客戶端向認(rèn)證服務(wù)器進(jìn)行身份認(rèn)證，并要求一個(gè)訪問令牌。

??? 認(rèn)證服務(wù)器確認(rèn)無誤后，向客戶端提供訪問令牌。