網(wǎng)絡(luò)安全已成為每個(gè)企業(yè)都面臨的關(guān)鍵問題。幾乎每天都有關(guān)于黑客如何竊取公司數(shù)據(jù)的頭條新聞。

為了開發(fā)安全的軟件并遠(yuǎn)離頭條新聞，企業(yè)需要解決各種安全問題，包括硬件的物理安全性、傳輸和靜態(tài)數(shù)據(jù)加密、身份驗(yàn)證、訪問授權(quán)以及修補(bǔ)軟件漏洞的策略，等等。

無論你使用的是單體還是微服務(wù)架構(gòu)，大多數(shù)問題都是相同的。本文重點(diǎn)介紹微服務(wù)架構(gòu)如何影響應(yīng)用程序級別的安全性。

應(yīng)用程序開發(fā)人員主要負(fù)責(zé)實(shí)現(xiàn)安全性的四個(gè)不同方面：

1、身份驗(yàn)證

驗(yàn)證嘗試訪問應(yīng)用程序的應(yīng)用程序或人員（安全的術(shù)語叫主體）的身份。例如，應(yīng)用程序通常會驗(yàn)證訪問的憑據(jù)，例如用戶的?ID?和密碼，或應(yīng)用程序的?API?密鑰。

2、訪問授權(quán)

驗(yàn)證是否允許訪問主體對指定數(shù)據(jù)完成請求的操作。應(yīng)用程序通常使用基于角色的安全性和訪問控制列表（ACL）的組合?；诮巧陌踩詾槊總€(gè)用戶分配一個(gè)或多個(gè)角色，授予他們調(diào)用特定操作的權(quán)限。ACL?授予用戶或角色對特定業(yè)務(wù)對象或聚合執(zhí)行操作的權(quán)限。

3、審計(jì)

跟蹤用戶在應(yīng)用中執(zhí)行的所有操作，以便檢測安全問題，幫助客戶實(shí)現(xiàn)并強(qiáng)制執(zhí)行合規(guī)性。

4、安全的進(jìn)程間通信

理想情況下，所有進(jìn)出服務(wù)的通信都應(yīng)該采用傳輸層安全性（TLS）加密。服務(wù)間通信甚至可能需要使用身份驗(yàn)證。

下面將重點(diǎn)介紹如何實(shí)現(xiàn)身份驗(yàn)證和訪問授權(quán)。審計(jì)和安全的進(jìn)程間通信的更多詳細(xì)介紹請參閱Chris Richardson的《微服務(wù)架構(gòu)設(shè)計(jì)模式》。

我首先描述如何在FTGO單體應(yīng)用程序中實(shí)現(xiàn)安全性。然后介紹在微服務(wù)架構(gòu)中實(shí)現(xiàn)安全性所面臨的挑戰(zhàn)，以及為何在單體架構(gòu)中運(yùn)行良好的技術(shù)不能在微服務(wù)架構(gòu)中使用。之后，我將介紹如何在微服務(wù)架構(gòu)中實(shí)現(xiàn)安全性。

讓我們首先回顧一下FTGO單體應(yīng)用程序如何處理安全性。

一、傳統(tǒng)單體應(yīng)用程序的安全性

FTGO應(yīng)用程序有多種用戶，包括消費(fèi)者、送餐員和餐館員工。他們使用基于瀏覽器的Web?應(yīng)用程序和移動應(yīng)用程序訪問FTGO。所有?FTGO?用戶都必須登錄才能訪問該應(yīng)用程序。圖?1顯示了單體FTGO?應(yīng)用程序的客戶端如何驗(yàn)證和發(fā)出請求。

圖1??FTGO?應(yīng)用程序的客戶首先登錄以獲取會話令牌，該令牌通常是?cookie。客戶在向FTGO?應(yīng)用程序發(fā)出的每個(gè)后續(xù)請求中都會包括會話令牌

當(dāng)用戶使用其用戶ID和密碼登錄時(shí)，客戶端會向FTGO應(yīng)用程序發(fā)出包含用戶憑據(jù)的POST?請求。FTGO?應(yīng)用程序驗(yàn)證憑據(jù)并將會話令牌返回給客戶端?？蛻舳嗽?FTGO?應(yīng)用程序的每個(gè)后續(xù)請求中包含會話令牌。

圖2顯示了FTGO應(yīng)用程序如何實(shí)現(xiàn)安全性。FTGO?應(yīng)用程序是用?Java?編寫的，并使用?Spring Security?框架，但我將使用同樣也適用于其他框架（例如?Passport for Node.js）的一般性術(shù)語來描述這個(gè)設(shè)計(jì)。

圖2　當(dāng)?FTGO?應(yīng)用程序的客戶端發(fā)出登錄請求時(shí)，登錄處理程序會對用戶進(jìn)行身份驗(yàn)證，初始化會話用戶信息，并返回會話令牌?cookie，以便安全地識別會話。接下來，當(dāng)客戶端發(fā)出包含會話令牌的請求時(shí)，SessionBasedSecurityInterceptor?從指定的會話中檢索用戶信息并建立安全上下文。請求處理程序（如OrderDetailsRequestHandler）從安全上下文中檢索用戶信息

使用安全框架

正確實(shí)現(xiàn)身份驗(yàn)證和訪問授權(quán)具有挑戰(zhàn)性。最好使用經(jīng)過驗(yàn)證的安全框架。使用哪個(gè)框架取決于你的應(yīng)用程序的技術(shù)棧。流行的框架包括以下幾個(gè)：

1、SpringSecurity

適用于Java應(yīng)用程序的流行框架。它是一個(gè)復(fù)雜的框架，可以處理身份驗(yàn)證和訪問授權(quán)。

2、ApacheShiro

另一個(gè)?Java?安全框架。

3、Passport

在Node.js應(yīng)用程序流行的一個(gè)專注于身份驗(yàn)證的安全框架。

安全架構(gòu)的一個(gè)關(guān)鍵部分是會話，它存儲主體的?ID?和角色。FTGO?應(yīng)用程序是傳統(tǒng)的Java EE?應(yīng)用程序，因此會話是?HttpSession?內(nèi)存中會話。會話令牌代表著每一個(gè)具體的會話，客戶端在每個(gè)請求中包含會話令牌。

它通常是一串無法讀懂的數(shù)字標(biāo)記，例如經(jīng)過加密的強(qiáng)隨機(jī)數(shù)。FTGO?應(yīng)用程序的會話令牌是一個(gè)名為JSESSIONID的HTTP cookie。

實(shí)現(xiàn)安全性的另一個(gè)關(guān)鍵是安全上下文，它存儲有關(guān)發(fā)出當(dāng)前請求的用戶的信息。Spring Security?框架使用標(biāo)準(zhǔn)的?Java EE?方法將安全上下文存儲在靜態(tài)的線程局部變量中，任何被調(diào)用以處理請求的代碼都可以訪問該變量。

請求處理程序可以調(diào)用?SecurityContextHolder. getContext().getAuthentication()?獲取有關(guān)當(dāng)前用戶的信息，例如他們的身份和角色。相反，Passport框架將安全上下文存儲為request對象的user屬性。

圖2?中顯示的事件序列如下：

1．客戶端向?FTGO?應(yīng)用程序發(fā)出登錄請求。

2．登錄請求由?LoginHandler?處理，LoginHandler?驗(yàn)證憑據(jù)，創(chuàng)建會話，并在會話中存儲有關(guān)主體的信息。

3．Login Handler?將會話令牌返回給客戶端。

4．客戶端在后續(xù)每次調(diào)用請求中都包含會話令牌。

5．這些請求首先由?SessionBasedSecurityInterceptor?處理。攔截器通過驗(yàn)證會話令牌來驗(yàn)證每個(gè)請求并建立安全上下文。安全上下文描述了主體及其角色。

6．請求處理程序使用安全上下文來獲取其身份，并借此確定是否允許用戶執(zhí)行請求的操作。

FTGO?應(yīng)用程序使用基于角色的授權(quán)。它定義了與不同類型用戶相對應(yīng)的幾個(gè)角色，包括?CONSUMER、RESTAURANT、COURIER和ADMIN。它使用Spring Security的聲明性安全機(jī)制來限制對特定角色的?URL?和服務(wù)方法的訪問。角色也與業(yè)務(wù)邏輯交織在一起。例如，消費(fèi)者只能訪問自己的訂單，而管理員可以訪問所有訂單。

單體FTGO應(yīng)用程序使用的安全設(shè)計(jì)只是實(shí)現(xiàn)安全性的一種可能方式。例如，使用內(nèi)存中會話的一個(gè)缺點(diǎn)是，它必須把特定會話的所有請求路由到同一個(gè)應(yīng)用程序?qū)嵗?。這個(gè)要求使負(fù)載均衡和操作變復(fù)雜了。

例如，你必須實(shí)現(xiàn)會話耗盡機(jī)制，該機(jī)制在關(guān)閉應(yīng)用程序?qū)嵗暗却袝挼狡?#xff08;以免丟失內(nèi)存中已有的會話）。避免這些問題的另一種方法是將會話存儲在數(shù)據(jù)庫中。

開發(fā)者可以完全不保存服務(wù)器端會話。例如，許多應(yīng)用程序都有?API?客戶端，可以在每個(gè)請求中提供其憑據(jù)，例如?API?密鑰和私鑰。因此，無須維護(hù)服務(wù)器端會話。

或者，應(yīng)用程序可以將會話狀態(tài)存儲在會話令牌中。在本文的后面，我將介紹一種使用會話令牌存儲會話狀態(tài)的方法。但讓我們首先看一下在微服務(wù)架構(gòu)中實(shí)現(xiàn)安全性的挑戰(zhàn)。

二、在微服務(wù)架構(gòu)中實(shí)現(xiàn)安全性

微服務(wù)架構(gòu)是分布式架構(gòu)。每個(gè)外部請求都由API Gateway和至少一個(gè)服務(wù)處理。例如，考慮getOrderDetails()查詢。API Gateway?通過調(diào)用多個(gè)服務(wù)來處理此查詢，包括Order Service、Kitchen Service?和?Accounting Service。每項(xiàng)服務(wù)都必須實(shí)現(xiàn)安全性的某些方面。

例如，Order Service必須只允許消費(fèi)者查看他們自己的訂單，這需要結(jié)合身份驗(yàn)證和訪問授權(quán)。為了在微服務(wù)架構(gòu)中實(shí)現(xiàn)安全性，我們需要確定誰負(fù)責(zé)驗(yàn)證用戶身份以及誰負(fù)責(zé)訪問授權(quán)。

在微服務(wù)應(yīng)用程序中實(shí)現(xiàn)安全性的一個(gè)挑戰(zhàn)是我們不能僅僅從單體應(yīng)用程序借鑒設(shè)計(jì)思路。這是因?yàn)閱误w應(yīng)用程序的安全架構(gòu)的一些方面對微服務(wù)架構(gòu)來說是不可用的，例如：

1、內(nèi)存中的安全上下文

使用內(nèi)存中的安全上下文（如ThreadLocal）來傳遞用戶身份。服務(wù)無法共享內(nèi)存，因此它們無法使用內(nèi)存中的安全上下文（如ThreadLocal）來傳遞用戶身份。在微服務(wù)架構(gòu)中，我們需要一種不同的機(jī)制來將用戶身份從一個(gè)服務(wù)傳遞到另一個(gè)服務(wù)。

2、集中會話

因?yàn)閮?nèi)存中的安全上下文沒有意義，內(nèi)存會話也沒有意義。從理論上講，多種服務(wù)可以訪問基于數(shù)據(jù)庫的會話，但它會違反松耦合的原則。我們需要在微服務(wù)架構(gòu)中使用不同的會話機(jī)制。

讓我們通過研究如何處理身份驗(yàn)證來開始探索微服務(wù)架構(gòu)中的安全性。

由?API Gateway?處理身份驗(yàn)證

處理身份驗(yàn)證有兩種不同的方法。一種選擇是讓各個(gè)服務(wù)分別對用戶進(jìn)行身份驗(yàn)證。這種方法的問題在于它允許未經(jīng)身份驗(yàn)證的請求進(jìn)入內(nèi)部網(wǎng)絡(luò)。它依賴于每個(gè)開發(fā)團(tuán)隊(duì)在所有服務(wù)中正確實(shí)現(xiàn)安全性。因此，出現(xiàn)安全漏洞的風(fēng)險(xiǎn)和概率都很大。

在服務(wù)中實(shí)現(xiàn)身份驗(yàn)證的另一個(gè)問題是不同的客戶端以不同的方式進(jìn)行身份驗(yàn)證。純API客戶端使用基本身份驗(yàn)證為每個(gè)請求提供憑據(jù)。其他客戶端可能首先登錄，然后為每個(gè)請求提供會話令牌。但我們要避免在服務(wù)中處理多種不同的身份驗(yàn)證機(jī)制。

更好的方法是讓API Gateway在將請求轉(zhuǎn)發(fā)給服務(wù)之前對其進(jìn)行身份驗(yàn)證。在API Gateway?中進(jìn)行集中API身份驗(yàn)證的優(yōu)勢在于只需要確保這里的驗(yàn)證是正確的。因此，出現(xiàn)安全漏洞的可能性要小得多。另一個(gè)好處是只有API Gateway需要處理各種不同的身份驗(yàn)證機(jī)制。這使得其他服務(wù)的實(shí)現(xiàn)變得簡單了。

圖3?顯示了這種方法的工作原理?？蛻舳耸褂?API Gateway進(jìn)行身份驗(yàn)證。API?客戶端在每個(gè)請求中包含憑據(jù)。基于登錄的客戶端將用戶的憑據(jù)發(fā)送到API Gateway進(jìn)行身份驗(yàn)證，并接收會話令牌。一旦API Gateway驗(yàn)證了請求，它就會調(diào)用一個(gè)或多個(gè)服務(wù)。

圖3 API Gateway?對來自客戶端的請求進(jìn)行身份驗(yàn)證，并在其對服務(wù)的請求中包含安全令牌。服務(wù)使用令牌獲取有關(guān)主體的信息。API Gateway?還可以將安全令牌用作會話令牌

模式：訪問令牌

API Gateway?將包含用戶信息（例如其身份和角色）的令牌傳遞給它調(diào)用的服務(wù)。請參閱：http://microservices.io/patterns/security/access-token.html。

API Gateway?調(diào)用的服務(wù)需要知道發(fā)出請求的主體（用戶的身份）。它還必須驗(yàn)證請求是否已經(jīng)過通過身份驗(yàn)證。解決方案是讓?API Gateway?在每個(gè)服務(wù)請求中包含一個(gè)令牌。服務(wù)使用令牌驗(yàn)證請求，并獲取有關(guān)主體的信息。API Gateway?還可以為面向會話的客戶端提供相同的令牌，以用作會話令牌。

客戶端的事件序列如下：

1．?客戶端發(fā)出包含憑據(jù)的請求給?API Gateway。

2．?API Gateway?對憑據(jù)進(jìn)行身份驗(yàn)證，創(chuàng)建安全令牌，并將其傳遞給服務(wù)。

基于登錄的客戶端的事件序列如下：

1．客戶端發(fā)出包含憑據(jù)的登錄請求。

2．API Gateway?返回安全令牌。

3．客戶端在調(diào)用操作的請求中包含安全令牌。

4．API Gateway?驗(yàn)證安全令牌并將其轉(zhuǎn)發(fā)給服務(wù)。

讓我們首先看一下安全性的另一個(gè)主要方面：訪問授權(quán)。

處理訪問授權(quán)

驗(yàn)證客戶端的憑據(jù)很重要，但這還不夠。應(yīng)用程序還必須實(shí)現(xiàn)訪問授權(quán)機(jī)制，以驗(yàn)證是否允許客戶端執(zhí)行所請求的操作。例如，在FTGO應(yīng)用程序中，getOrderDetails()查詢只能由下此?Order?的消費(fèi)者（基于實(shí)例的安全性的一個(gè)示例）和為所有消費(fèi)者提供服務(wù)的客戶服務(wù)代表調(diào)用。

實(shí)現(xiàn)訪問授權(quán)的一個(gè)位置是?API Gateway。例如，它可以將對?GET/orders/{orderId}的訪問限制為消費(fèi)者和客戶服務(wù)代表。如果不允許用戶訪問特定路徑，則API Gateway可以在將請求轉(zhuǎn)發(fā)到服務(wù)之前拒絕該請求。

與身份驗(yàn)證一樣，在API Gateway中集中實(shí)現(xiàn)訪問授權(quán)可降低安全漏洞的風(fēng)險(xiǎn)。你可以使用安全框架（如?Spring Security）在API Gateway中實(shí)現(xiàn)訪問授權(quán)。

在?API Gateway?中實(shí)現(xiàn)訪問授權(quán)的一個(gè)弊端是，它有可能產(chǎn)生API Gateway與服務(wù)之間的耦合，要求它們以同步的方式進(jìn)行代碼更新。而且，API Gateway通常只能實(shí)現(xiàn)對URL路徑的基于角色的訪問。由?API Gateway?實(shí)現(xiàn)對單個(gè)領(lǐng)域?qū)ο蟮脑L問授權(quán)通常是不實(shí)際的，因?yàn)檫@需要詳細(xì)了解服務(wù)的領(lǐng)域邏輯。

另一個(gè)實(shí)現(xiàn)訪問授權(quán)的位置是服務(wù)。服務(wù)可以對URL和服務(wù)方法實(shí)現(xiàn)基于角色的訪問授權(quán)。它還可以實(shí)現(xiàn)?ACL?來管理對聚合的訪問。例如，在Order Service中可以實(shí)現(xiàn)基于角色和基于ACL的授權(quán)機(jī)制，以控制對?Order的訪問。FTGO應(yīng)用程序中的其他服務(wù)也可以實(shí)現(xiàn)類似的訪問授權(quán)邏輯。

使用?JWT?傳遞用戶身份和角色

在微服務(wù)架構(gòu)中實(shí)現(xiàn)安全性時(shí)，你需要確定?API Gateway應(yīng)使用哪種類型的令牌來將用戶信息傳遞給服務(wù)。有兩種類型的令牌可供選擇。一種選擇是使用不透明（無可讀性）的令牌，它們通常是一串UUID。

不透明令牌的缺點(diǎn)是它們會降低性能和可用性，并增加延遲。因?yàn)檫@種令牌的接收方必須對安全服務(wù)發(fā)起同步?RPC?調(diào)用，以驗(yàn)證令牌并檢索用戶信息。

另一種消除對安全服務(wù)調(diào)用的方法是使用包含有關(guān)用戶信息的透明令牌。透明令牌的一個(gè)流行的標(biāo)準(zhǔn)是?JSON Web令牌（JWT）。JWT是在訪問雙方之間安全地傳遞信息（例如用戶身份和角色）的標(biāo)準(zhǔn)方式。

JWT?的內(nèi)容包含一個(gè)JSON對象，其中有用戶的信息，例如其身份和角色，以及其他元數(shù)據(jù)，如到期日期等。它使用僅為JWT的創(chuàng)建者所知的數(shù)字簽名，例如?API Gateway和JWT的接收者（服務(wù)）。該簽名確保惡意第三方不能偽造或篡改JWT。

因?yàn)椴恍枰僭L問安全服務(wù)進(jìn)行驗(yàn)證，JWT的一個(gè)問題是這個(gè)令牌是自包含的，也就是說它是不可撤消的。根據(jù)設(shè)計(jì)，服務(wù)將在驗(yàn)證?JWT?的簽名和到期日期之后執(zhí)行請求操作。

因此，沒有切實(shí)可行的方法來撤消落入惡意第三方手中的某個(gè)JWT令牌。解決方案是發(fā)布具有較短到期時(shí)間的?JWT，這可以限制惡意方。但是，短期JWT的一個(gè)缺點(diǎn)是應(yīng)用程序必須以某種方式不斷重新發(fā)布JWT以保持會話活動。幸運(yùn)的是，這是?OAuth 2.0?安全標(biāo)準(zhǔn)旨在解決的眾多問題之一。讓我們來看看它是如何工作的。

在微服務(wù)架構(gòu)中使用OAuth 2.0

假設(shè)你要為FTGO應(yīng)用程序?qū)崿F(xiàn)一個(gè)User Service，該應(yīng)用程序管理包含用戶信息（如憑據(jù)和角色）的數(shù)據(jù)庫。API Gateway?調(diào)用User Service?來驗(yàn)證客戶端請求并獲取JWT。你可以設(shè)計(jì)User Service的API并使用你喜歡的Web框架實(shí)現(xiàn)它。但這不是FTGO應(yīng)用程序特有的通用功能，自己開發(fā)此類服務(wù)往往是得不償失的。

幸運(yùn)的是，你不需要開發(fā)這種安全基礎(chǔ)設(shè)施。你可以使用名為OAuth 2.0的標(biāo)準(zhǔn)的現(xiàn)成服務(wù)或框架。OAuth 2.0?是一種訪問授權(quán)協(xié)議，最初旨在使公共云服務(wù)（如GitHub或Google）的用戶能夠授予第三方應(yīng)用程序訪問其信息的權(quán)限，而不必向第三方應(yīng)用透露他們的密碼。例如，OAuth 2.0使你能夠安全地授予第三方基于云的持續(xù)集成（CI）服務(wù)，訪問你的GitHub存儲庫。

雖然?OAuth 2.0?最初的重點(diǎn)是授權(quán)訪問公共云服務(wù)，但你也可以將其用于應(yīng)用程序中的身份驗(yàn)證和訪問授權(quán)。讓我們快速了解一下微服務(wù)架構(gòu)如何使用?OAuth 2.0。

OAuth 2.0?中的關(guān)鍵概念如下：

1、授權(quán)服務(wù)器：提供用于驗(yàn)證用戶身份以及獲取訪問令牌和刷新令牌的?API。Spring OAuth是一個(gè)很好的用來構(gòu)建OAuth 2.0授權(quán)服務(wù)器的框架。

2、訪問令牌：授予對資源服務(wù)器的訪問權(quán)限的令牌。訪問令牌的格式取決于具體的實(shí)現(xiàn)技術(shù)。Spring OAuth?的實(shí)現(xiàn)中采用了JWT格式的訪問令牌。

3、刷新令牌：客戶端用于獲取新的AccessToken的長效但同時(shí)也可被可撤消的令牌。

4、資源服務(wù)器：使用訪問令牌授權(quán)訪問的服務(wù)。在微服務(wù)架構(gòu)中，服務(wù)是資源服務(wù)器。

5、客戶端：想要訪問資源服務(wù)器的客戶端。在微服務(wù)架構(gòu)中，API Gateway?是OAuth 2.0客戶端。

首先，我們來談?wù)勅绾悟?yàn)證API客戶端，然后介紹如何支持基于登錄的客戶端。

圖?4?顯示了API Gateway如何驗(yàn)證來自API客戶端的請求。API Gateway通過向OAuth 2.0授權(quán)服務(wù)器發(fā)出請求來驗(yàn)證API客戶端，該服務(wù)器返回訪問令牌。然后，API Gateway將包含訪問令牌的一個(gè)或多個(gè)請求發(fā)送到服務(wù)。

圖4 API Gateway?通過向?OAuth 2.0?身份驗(yàn)證服務(wù)器發(fā)出請求來驗(yàn)證?API?客戶端。身份驗(yàn)證服務(wù)器返回訪問令牌，API Gateway?將其傳遞給服務(wù)。服務(wù)驗(yàn)證令牌的簽名，并提取有關(guān)用戶的信息，包括其身份和角色

圖4?所示的事件順序如下：

1、客戶端發(fā)出請求，使用基本身份驗(yàn)證提供它的憑據(jù)。

2、API Gateway?向?OAuth 2.0?身份驗(yàn)證服務(wù)器發(fā)出?OAuth 2.0?密碼授予（Password Grant）請求（www.oauth.com/oauth2-servers/access-tokens/password-grant/）。

3、身份驗(yàn)證服務(wù)器驗(yàn)證?API?客戶端的憑據(jù)，并返回訪問令牌和刷新令牌。

4、API Gateway?在其對服務(wù)的請求中包含訪問令牌。服務(wù)驗(yàn)證訪問令牌并使用它來授權(quán)請求。

基于?OAuth 2.0?的API Gateway可以使用OAuth 2.0訪問令牌作為會話令牌來驗(yàn)證面向會話的客戶端。而且，當(dāng)訪問令牌到期時(shí)，它可以使用刷新令牌獲得新的訪問令牌。

圖5顯示了API Gateway如何使用OAuth 2.0來處理面向會話的客戶端。API客戶端通過將其憑據(jù)（發(fā)送?POST）到API Gateway的/login?端點(diǎn)來啟動會話。API Gateway?向客戶端返回訪問令牌和刷新令牌。然后，API客戶端在向API Gateway發(fā)出請求時(shí)提供這兩個(gè)令牌。

圖5　客戶端通過將其憑據(jù)發(fā)送到?API Gateway?來登錄。API Gateway?使用?OAuth 2.0?身份驗(yàn)證服務(wù)器對憑據(jù)進(jìn)行身份驗(yàn)證，并將訪問令牌和刷新令牌作為?cookie?返回。客戶端在其對?API Gateway?的請求中包括這些令牌

事件順序如下：

1.?基于登錄的客戶端將其憑據(jù)發(fā)送到?API Gateway。

2. API Gateway的LoginHandler向OAuth 2.0身份驗(yàn)證服務(wù)器發(fā)出密碼授予請求（www.?oauth.com/oauth2-servers/access-tokens/password-grant/）。

3.?身份驗(yàn)證服務(wù)器驗(yàn)證客戶端的憑據(jù)，并返回訪問令牌和刷新令牌。

4. API Gateway?將訪問令牌和刷新令牌返回給客戶端，通常是采用?cookie?的形式。

5.?客戶端在向?API Gateway?發(fā)出的請求中包含訪問令牌和刷新令牌。

6. API Gateway?的?Session Authentication Interceptor?驗(yàn)證訪問令牌，并將其包含在對服務(wù)的請求中。

如果訪問令牌已經(jīng)過期或即將過期，API Gateway?將通過發(fā)出?OAuth 2.0?刷新授權(quán)請求來獲取新的訪問令牌（www.oauth.com/oauth2-servers/access-tokens/refresh-access-tokens/），刷新授權(quán)請求發(fā)送給授權(quán)服務(wù)器，請求中包含刷新令牌。如果刷新令牌尚未過期或未被撤消，則授權(quán)服務(wù)器將返回新的訪問令牌。API Gateway?將新的訪問令牌傳遞給服務(wù)并將其返回給客戶端。

使用?OAuth 2.0?的一個(gè)重要好處是它是經(jīng)過驗(yàn)證的安全標(biāo)準(zhǔn)。使用現(xiàn)成的?OAuth 2.0?身份驗(yàn)證服務(wù)器意味著你不必浪費(fèi)時(shí)間重新發(fā)明輪子或者是沒有開發(fā)不安全的設(shè)計(jì)的風(fēng)險(xiǎn)。

但OAuth 2.0?不是在微服務(wù)架構(gòu)中實(shí)現(xiàn)安全性的唯一方法。無論你使用哪種方法，三個(gè)關(guān)鍵思想如下：

1、API Gateway?負(fù)責(zé)驗(yàn)證客戶端的身份。

2、API Gateway?和服務(wù)使用透明令牌（如?JWT）來傳遞有關(guān)主體的信息。

3、服務(wù)使用令牌獲取主體的身份和角色。

總結(jié)

以上是生活随笔為你收集整理的微服务架构如何保证安全性？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。