微服務(wù)架構(gòu)下的安全認證與鑒權(quán)

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

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

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

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

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

1. 單點登錄（SSO）

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

2. 分布式 Session 方案

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

3. 客戶端 Token 方案

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

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

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

微服務(wù)常見安全認證方案

HTTP 基本認證

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

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

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

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

服務(wù)器將 Authorization Header 中的用戶名密碼取出，進行驗證， 如果驗證通

過，將根據(jù)請求，發(fā)送資源給客戶端。

基于 Session 的認證

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

但是在分布式架構(gòu)下，Session 存放于某個具體的應(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)提供了這個能力。

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

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

基于 Token 的認證

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

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

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

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

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

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

基于 Token 認證的好處如下：

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

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

支持移動設(shè)備。

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

下面會重點介紹兩種基于 Token 的認證方案 JWT/Oauth2.0。

JWT 介紹

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

JWT 認證流程

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

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

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

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

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

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

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

header.payload.signature

1. 頭部（Header）

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

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

2. 載荷（payload）

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

標(biāo)準中注冊的聲明

公共的聲明

私有的聲明

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

iss：JWT 簽發(fā)者

sub：JWT 所面向的用戶

aud：接收 JWT 的一方

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

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

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

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

公共的聲明 ：

公共的聲明可以添加任何的信息，一般添加用戶的相關(guān)信息或其他業(yè)務(wù)需要的必要信息. 但不建議添加敏感信息，因為該部分在客戶端可解密。

私有的聲明 ：

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

示例如下：

3. 簽名（signature)

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

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

JWT 的優(yōu)點：

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

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

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

關(guān)于 Token 注銷：

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

Token 存儲在 Cookie 中，這樣客戶端注銷時，自然可以清空掉。

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

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

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)準的方式去訪問需要用戶授權(quán)的 API 服務(wù)。OAUTH 認證授權(quán)具有以下特點：

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

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

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

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

授權(quán)流程

OAuth 2.0 的流程如下：

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

四大角色

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

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

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

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

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

客戶端的授權(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）是功能最完整、流程最嚴密的授權(quán)模式。它的特點就是通過客戶端的后臺服務(wù)器，與 " 服務(wù)提供商 " 的認證服務(wù)器進行互動。流程如下：

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

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

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

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

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

2. 簡化模式（implicit）

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

1、客戶端將用戶導(dǎo)向認證服務(wù)器。

2、用戶決定是否給予客戶端授權(quán)。

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

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

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

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

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

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

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

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

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

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

4. 客戶端模式（Client Credentials）

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

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

1、客戶端向認證服務(wù)器進行身份認證，并要求一個訪問令牌。

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

思考總結(jié)

正如 David Borsos 所建議的一種方案，在微服務(wù)架構(gòu)下，我們更傾向于將 Oauth 和 JWT 結(jié)合使用，Oauth 一般用于第三方接入的場景，管理對外的權(quán)限，所以比較適合和 API 網(wǎng)關(guān)結(jié)合，針對于外部的訪問進行鑒權(quán)（當(dāng)然，底層 Token 標(biāo)準采用 JWT 也是可以的）。

JWT 更加輕巧，在微服務(wù)之間進行訪問鑒權(quán)已然足夠，并且可以避免在流轉(zhuǎn)過程中和身份認證服務(wù)打交道。當(dāng)然，從能力實現(xiàn)角度來說，類似于分布式 Session 在很多場景下也是完全能滿足需求，具體怎么去選擇鑒權(quán)方案，還是要結(jié)合實際的需求來。

原文：?https://www.infoq.cn/article/UiB7aRK52MYROa2kL7Xf

數(shù)據(jù)庫 架構(gòu)設(shè)計 運維 大數(shù)據(jù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。