轉(zhuǎn)向微服務(wù)時，將得出結(jié)論，與單應(yīng)體用程序相比，需要以不同的方式解決保護(hù)微服務(wù)的問題。

在設(shè)計(jì)解決方案時，會出現(xiàn)諸如"我在哪里以及如何實(shí)現(xiàn)身份驗(yàn)證和授權(quán)?"之類的問題。和"我如何授權(quán)用戶采取特定行動?"可以彈出。在本文中，將為這些問題介紹一種解決方案。

首先，將說明認(rèn)證和授權(quán)之間的差異。其次，將引入OpenID Connect和OAuth2作為用于微服務(wù)架構(gòu)的集中式身份驗(yàn)證和授權(quán)的解決方案。最后，將解釋授權(quán)的兩個實(shí)現(xiàn)選擇。

[[358250]]

身份驗(yàn)證和授權(quán)之間有什么區(qū)別?

在談?wù)摫Ｗo(hù)應(yīng)用程序安全時，將彈出認(rèn)證和授權(quán)一詞。雖然這些術(shù)語可以互換使用，但它們在保護(hù)應(yīng)用程序范圍內(nèi)代表了不同的目的。

在談?wù)撋矸蒡?yàn)證時，這是驗(yàn)證他/她/所聲稱的實(shí)體的身份的過程。在談?wù)撌跈?quán)時，它是驗(yàn)證實(shí)體是否被授權(quán)訪問特定信息或被允許執(zhí)行某些動作的過程。

關(guān)于總安全流程，這兩個原則都適用，并且組合仍然可能使請求失敗。在規(guī)則中，身份驗(yàn)證首先，授權(quán)第二。當(dāng)用戶通過身份驗(yàn)證但未經(jīng)授權(quán)時，請求仍將失敗。

OpenID Connect和OAuth

在像微服務(wù)這樣的分布式系統(tǒng)架構(gòu)中，無法以傳統(tǒng)方式實(shí)現(xiàn)身份驗(yàn)證和授權(quán)。使用單體架構(gòu)方法，經(jīng)常將簽名會話存儲在內(nèi)存中或分布式會話存儲中，以在單體應(yīng)用程序?qū)嵗g共享會話。

由于微服務(wù)是單獨(dú)的隔離的應(yīng)用程序，因此無法共享不同應(yīng)用程序的內(nèi)存中存儲。不建議集中和共享分布式會話存儲。這在微服務(wù)之間建立了緊密的耦合，并為微服務(wù)之間的泄漏邏輯打開了大門。

牢記微服務(wù)架構(gòu)，每個微服務(wù)應(yīng)獨(dú)自負(fù)責(zé)其單個業(yè)務(wù)邏輯，無論是很小的邏輯還是有限的上下文。在這種情況下，身份驗(yàn)證是一個貫穿各領(lǐng)域的問題，不應(yīng)成為微服務(wù)本身的一部分。

針對此問題的一種廣泛使用的解決方案是實(shí)現(xiàn)單獨(dú)的身份服務(wù)器。該服務(wù)負(fù)責(zé)托管集中式身份驗(yàn)證和授權(quán)。有多種解決方案，例如WSO2身份服務(wù)器(Java)，IdentityServer4(.NET)和OAuth2orize(Node.js)。所有這些框架都通過使用OpenID Connect和OAuth2支持身份驗(yàn)證和授權(quán)。

什么是OpenID Connect?

OpenID Connect是一種身份驗(yàn)證協(xié)議，它是OAuth2之上的簡單身份層。它允許客戶端識別客戶端，以通過外部授權(quán)服務(wù)器(例如Google，F(xiàn)acebook或身份服務(wù)器中的嵌入式登錄系統(tǒng))來驗(yàn)證用戶的身份。

流程看起來如何?用戶請求訪問應(yīng)用程序。應(yīng)用程序確定用戶尚未通過身份驗(yàn)證，然后將用戶重定向到身份服務(wù)器。用戶向身份服務(wù)器進(jìn)行身份驗(yàn)證。身份服務(wù)器在成功身份驗(yàn)證后向用戶發(fā)送訪問令牌/ ID令牌。該令牌由加密密鑰簽名。用戶可以在應(yīng)用程序上使用此令牌進(jìn)行身份驗(yàn)證。應(yīng)用程序通過檢查公共加密密鑰來檢查簽名密鑰是否由身份服務(wù)器簽名，從而驗(yàn)證簽名密鑰。在這種情況下，用戶已成功通過身份驗(yàn)證!

對于令牌，使用JSON Web令牌(JWT)。JWT由標(biāo)頭，有效負(fù)載和簽名組成。標(biāo)頭包含用于對令牌進(jìn)行簽名的算法。有效負(fù)載本質(zhì)上是一個JSON對象，可以在其中添加有關(guān)用戶的其他屬性。由于令牌是由身份服務(wù)器簽名的，因此消費(fèi)應(yīng)用程序可以信任該信息。應(yīng)用程序可以根據(jù)身份服務(wù)器用于簽署令牌的證書的公鑰來驗(yàn)證令牌。

> High-level flow between user, application and identity server

什么是OAuth2?

在解釋OpenID Connect時，術(shù)語OAuth2已經(jīng)掉了。OAuth2是行業(yè)標(biāo)準(zhǔn)的授權(quán)協(xié)議。它為Web應(yīng)用程序，臺式機(jī)應(yīng)用程序，移動電話和客廳設(shè)備提供了特定的授權(quán)流程(在規(guī)范內(nèi)稱為授予)。

OpenID Connect解釋中描述的流程實(shí)際上使用了一種受支持的授權(quán)類型，確切地說是授權(quán)碼授權(quán)類型。

通過此流程，將用戶重定向到身份服務(wù)器，在該服務(wù)器上處理身份驗(yàn)證和授權(quán)?？蛻舳?請求用戶信息的應(yīng)用程序)獲得用戶對所需信息的授權(quán)。這是通過配置正確的作用域來完成的。范圍類似于特定客戶端可以訪問的數(shù)據(jù)類型。范圍的示例是電子郵件和地址，分別類似于用戶的電子郵件地址和地址。

范圍是由應(yīng)用程序在身份驗(yàn)證過程中請求的。當(dāng)用戶在身份服務(wù)器上對自己進(jìn)行身份驗(yàn)證時，用戶也有可能為請求的數(shù)據(jù)授予應(yīng)用程序授權(quán)。獲得授權(quán)后，數(shù)據(jù)將被添加到令牌的有效載荷中并傳遞給應(yīng)用程序。

在身份服務(wù)器中，可以保留與用戶連接的角色?？梢詾楣局械乃袉T工設(shè)置身份服務(wù)器。這些員工根據(jù)他們在公司中的角色具有不同的角色。身份服務(wù)器可以將分配的角色共享給令牌中的特定用戶。這樣，可以與使用中的應(yīng)用程序共享。

特定于應(yīng)用程序的授權(quán)邏輯應(yīng)內(nèi)置在哪里?

上一節(jié)已經(jīng)提倡選擇在單獨(dú)的集中負(fù)責(zé)的服務(wù)中構(gòu)建身份驗(yàn)證。對于特定于應(yīng)用程序的授權(quán)邏輯，這變得更加困難。在微服務(wù)架構(gòu)中，服務(wù)本身不應(yīng)直接暴露給使用中的應(yīng)用程序。管理與所有微服務(wù)的連接變得難以管理。

實(shí)施API網(wǎng)關(guān)會創(chuàng)建一個供消費(fèi)者與之通信的單一入口點(diǎn)。API網(wǎng)關(guān)將請求路由到上游微服務(wù)。

> API gateway in relation to other components

當(dāng)有多個使用者使用時，創(chuàng)建特定的API網(wǎng)關(guān)可能是為每個使用者創(chuàng)建單獨(dú)的特定端點(diǎn)的解決方案。這種變化稱為"前端的后端"模式。這樣，僅為每個使用者專門實(shí)現(xiàn)端點(diǎn)。這樣做的缺點(diǎn)是，它為每個使用者增加了另一個需要維護(hù)的單獨(dú)服務(wù)。

在網(wǎng)關(guān)中處理特定于應(yīng)用程序的授權(quán)

處理特定于應(yīng)用程序的授權(quán)的一種解決方案是通過在API網(wǎng)關(guān)中實(shí)現(xiàn)此功能。以這種方式將請求限制到特定端點(diǎn)成為可能。在API網(wǎng)關(guān)中實(shí)現(xiàn)授權(quán)的缺點(diǎn)是，它只能是基于角色的端點(diǎn)訪問。實(shí)施對特定域?qū)ο蟮脑L問的附加檢查將需要在API網(wǎng)關(guān)內(nèi)部創(chuàng)建特定域邏輯，因此將導(dǎo)致域邏輯泄漏。此外，在為前端/ API網(wǎng)關(guān)引入多個后端時，管理授權(quán)變得越來越困難。

在微服務(wù)中處理特定于應(yīng)用程序的授權(quán)

更好的解決方案是使微服務(wù)負(fù)責(zé)處理授權(quán)。API網(wǎng)關(guān)應(yīng)將JWT與請求一起傳遞給微服務(wù)。如前所述，JWT將包含分配給用戶的角色。由于API網(wǎng)關(guān)仍負(fù)責(zé)身份驗(yàn)證，因此在微服務(wù)收到請求時，已經(jīng)完成了令牌的驗(yàn)證。通過為執(zhí)行請求的用戶分配角色，微服務(wù)現(xiàn)在可以確定用戶是否已獲得所需請求的授權(quán)。這樣，只需要在一個地方實(shí)現(xiàn)特定于應(yīng)用程序。這樣做的一個缺點(diǎn)是授權(quán)將分散在多個服務(wù)中。當(dāng)許多角色經(jīng)常變化時，管理起來就變得很乏味。

結(jié)論

當(dāng)在微服務(wù)中實(shí)現(xiàn)身份驗(yàn)證和授權(quán)時，該過程比傳統(tǒng)的單片架構(gòu)要復(fù)雜得多。

雖然身份驗(yàn)證和授權(quán)都是保護(hù)應(yīng)用程序安全的術(shù)語，但它們涵蓋的范圍并不相同。身份驗(yàn)證是關(guān)于驗(yàn)證其聲稱為實(shí)體的身份。授權(quán)是有關(guān)確定是否允許實(shí)體執(zhí)行特定操作或訪問特定數(shù)據(jù)的過程。

對微服務(wù)架構(gòu)內(nèi)的應(yīng)用程序的身份驗(yàn)證和授權(quán)通常是在對此負(fù)責(zé)的集中式服務(wù)中實(shí)現(xiàn)的。有多種解決方案，例如WSO2身份服務(wù)器(Java)，IdentityServer4(.NET)和OAuth2orize(Node.js)。這些服務(wù)支持OAuth2和OpenID Connect，它們是用于授權(quán)和身份驗(yàn)證的基礎(chǔ)，行業(yè)標(biāo)準(zhǔn)協(xié)議。

實(shí)施身份驗(yàn)證檢查應(yīng)在API網(wǎng)關(guān)內(nèi)部終止?？梢栽贏PI網(wǎng)關(guān)或微服務(wù)中實(shí)現(xiàn)授權(quán)。為了能夠進(jìn)行廣泛的特定于應(yīng)用程序的授權(quán)檢查，應(yīng)該在特定的微服務(wù)中處理授權(quán)。這可以通過將JWT與請求一起傳遞來完成。這樣，域?qū)ο蟮奶囟ㄓ趹?yīng)用程序的授權(quán)就不會泄漏到API網(wǎng)關(guān)。