從單體應(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)方案也在不斷的變革。面對(duì)數(shù)十個(gè)甚至上百個(gè)微服務(wù)之間的調(diào)用，如何保證高效安全的身份認(rèn)證？面對(duì)外部的服務(wù)訪問，該如何提供細(xì)粒度的鑒權(quán)方案？本文將會(huì)為大家闡述微服務(wù)架構(gòu)下的安全認(rèn)證與鑒權(quán)方案。

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

而微服務(wù)架構(gòu)下，一個(gè)應(yīng)用會(huì)被拆分成若干個(gè)微應(yīng)用，每個(gè)微應(yīng)用都需要對(duì)訪問進(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)用接入的場(chǎng)景、用戶 - 服務(wù)的鑒權(quán)、服務(wù) - 服務(wù)的鑒權(quán)等多種鑒權(quán)場(chǎng)景。

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

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

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

2. 分布式 Session 方案

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

3. 客戶端 Token 方案

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

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

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

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ù)器會(huì)返回一個(gè) 401 Unauthozied 給客戶端，并且在 Response 的 Header 'WWW-Authenticate' 中添加信息。

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

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

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

基于 Session 的認(rèn)證

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

但是在分布式架構(gòu)下，Session 存放于某個(gè)具體的應(yīng)用服務(wù)器中自然就無法滿足使用了，簡(jiǎn)單的可以通過 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ù)制會(huì)占用較多網(wǎng)絡(luò)資源。Session 粘滯是通過負(fù)載均衡器，將統(tǒng)一用戶的請(qǐng)求都分發(fā)到固定的服務(wù)器節(jié)點(diǎn)上，這樣就保證了對(duì)某一用戶而言，Session 數(shù)據(jù)始終是正確的。不過這種方案依賴于負(fù)載均衡器，并且只能滿足水平擴(kuò)展的集群場(chǎng)景，無法滿足應(yīng)用分割后的分布式場(chǎng)景。

在微服務(wù)架構(gòu)下，每個(gè)微服務(wù)拆分的粒度會(huì)很細(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 一般會(huì)包含用戶的相關(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)證登錄信息是否正確，返回接口（一般接口中會(huì)包含用戶基礎(chǔ)信息、權(quán)限范圍、有效時(shí)間等信息），客戶端存儲(chǔ)接口，可以存儲(chǔ)在 Session 或者數(shù)據(jù)庫中。

• 用戶將 Token 放在 HTTP 請(qǐng)求頭中，發(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ù)端不需要存儲(chǔ) session 信息，因?yàn)?Token 自身包含了所有用戶的相關(guān)信息。

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

• 支持移動(dòng)設(shè)備。

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

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

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ù)穆暶鳌WT 一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該 Token 也可直接被用于認(rèn)證，也可被加密。

JWT 認(rèn)證流程

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

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

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

• 客戶端拿到 JWT，進(jìn)行存儲(chǔ)（可以存儲(chǔ)在緩存中，也可以存儲(chǔ)在數(shù)據(jù)庫中，如果是瀏覽器，可以存儲(chǔ)在 Cookie 中）在后續(xù)請(qǐng)求中，在 HTTP 請(qǐng)求頭中加上 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 對(duì)象，將每一段 JSON 對(duì)象采用 BASE64 編碼，將編碼后的內(nèi)容用. 鏈接一起就構(gòu)成了 JWT 字符串。如下：

header.payload.signature

1. 頭部（Header）

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

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

2. 載荷（payload）

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

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

• 公共的聲明

• 私有的聲明

標(biāo)準(zhǔn)中注冊(cè)的聲明（建議但不強(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)識(shí)，主要用來作為一次性 token, 從而回避重放攻擊。

公共的聲明 ：

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

私有的聲明 ：

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

示例如下：

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

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

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

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

  
  

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)用提供了一種簡(jiǎn)單的，標(biāo)準(zhǔn)的方式去訪問需要用戶授權(quán)的 API 服務(wù)。OAUTH 認(rèn)證授權(quán)具有以下特點(diǎn)：

簡(jiǎ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ā)者的簡(jiǎn)易性。要么通過組織在資源擁有者和 HTTP 服務(wù)商之間的被批準(zhǔn)的交互動(dòng)作代表用戶，要么允許第三方應(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ù)器申請(qǐng)令牌。（D）認(rèn)證服務(wù)器對(duì)客戶端進(jìn)行認(rèn)證以后，確認(rèn)無誤，同意發(fā)放令牌。（E）客戶端使用令牌，向資源服務(wù)器申請(qǐng)獲取資源。（F）資源服務(wù)器確認(rèn)令牌無誤，同意向客戶端開放資源。

四大角色

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

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

• 資源擁有者：資源擁有者是對(duì)資源具有授權(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)就是通過客戶端的后臺(tái)服務(wù)器，與'服務(wù)提供商'的認(rèn)證服務(wù)器進(jìn)行互動(dòng)。流程如下：

用戶訪問客戶端，后者將前者導(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ù)器申請(qǐng)令牌。這一步是在客戶端的后臺(tái)的服務(wù)器上完成的，對(duì)用戶不可見。

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

2. 簡(jiǎn)化模式（implicit）

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 客戶端模式（Client Credentials）

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

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

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

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

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

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

出處：https://mp.weixin.qq.com/s/x0CZpovseOuofTA_lw0HvA