微服务架构如何保证安全性?
網(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 敢不敢模拟超过 5 万的并发用户?
- 下一篇: 一个39岁程序员的应聘被拒