轉向微服務時，將得出結論，與單應體用程序相比，需要以不同的方式解決保護微服務的問題。

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

首先，將說明認證和授權之間的差異。其次，將引入OpenID Connect和OAuth2作為用于微服務架構的集中式身份驗證和授權的解決方案。最后，將解釋授權的兩個實現選擇。

[[358250]]

身份驗證和授權之間有什么區別?

在談論保護應用程序安全時，將彈出認證和授權一詞。雖然這些術語可以互換使用，但它們在保護應用程序范圍內代表了不同的目的。

在談論身份驗證時，這是驗證他/她/所聲稱的實體的身份的過程。在談論授權時，它是驗證實體是否被授權訪問特定信息或被允許執行某些動作的過程。

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

OpenID Connect和OAuth

在像微服務這樣的分布式系統架構中，無法以傳統方式實現身份驗證和授權。使用單體架構方法，經常將簽名會話存儲在內存中或分布式會話存儲中，以在單體應用程序實例之間共享會話。

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

牢記微服務架構，每個微服務應獨自負責其單個業務邏輯，無論是很小的邏輯還是有限的上下文。在這種情況下，身份驗證是一個貫穿各領域的問題，不應成為微服務本身的一部分。

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

什么是OpenID Connect?

OpenID Connect是一種身份驗證協議，它是OAuth2之上的簡單身份層。它允許客戶端識別客戶端，以通過外部授權服務器(例如Google，Facebook或身份服務器中的嵌入式登錄系統)來驗證用戶的身份。

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

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

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

什么是OAuth2?

在解釋OpenID Connect時，術語OAuth2已經掉了。OAuth2是行業標準的授權協議。它為Web應用程序，臺式機應用程序，移動電話和客廳設備提供了特定的授權流程(在規范內稱為授予)。

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

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

范圍是由應用程序在身份驗證過程中請求的。當用戶在身份服務器上對自己進行身份驗證時，用戶也有可能為請求的數據授予應用程序授權。獲得授權后，數據將被添加到令牌的有效載荷中并傳遞給應用程序。

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

特定于應用程序的授權邏輯應內置在哪里?

上一節已經提倡選擇在單獨的集中負責的服務中構建身份驗證。對于特定于應用程序的授權邏輯，這變得更加困難。在微服務架構中，服務本身不應直接暴露給使用中的應用程序。管理與所有微服務的連接變得難以管理。

實施API網關會創建一個供消費者與之通信的單一入口點。API網關將請求路由到上游微服務。

> API gateway in relation to other components

當有多個使用者使用時，創建特定的API網關可能是為每個使用者創建單獨的特定端點的解決方案。這種變化稱為"前端的后端"模式。這樣，僅為每個使用者專門實現端點。這樣做的缺點是，它為每個使用者增加了另一個需要維護的單獨服務。

在網關中處理特定于應用程序的授權

處理特定于應用程序的授權的一種解決方案是通過在API網關中實現此功能。以這種方式將請求限制到特定端點成為可能。在API網關中實現授權的缺點是，它只能是基于角色的端點訪問。實施對特定域對象的訪問的附加檢查將需要在API網關內部創建特定域邏輯，因此將導致域邏輯泄漏。此外，在為前端/ API網關引入多個后端時，管理授權變得越來越困難。

在微服務中處理特定于應用程序的授權

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

結論

當在微服務中實現身份驗證和授權時，該過程比傳統的單片架構要復雜得多。

雖然身份驗證和授權都是保護應用程序安全的術語，但它們涵蓋的范圍并不相同。身份驗證是關于驗證其聲稱為實體的身份。授權是有關確定是否允許實體執行特定操作或訪問特定數據的過程。

對微服務架構內的應用程序的身份驗證和授權通常是在對此負責的集中式服務中實現的。有多種解決方案，例如WSO2身份服務器(Java)，IdentityServer4(.NET)和OAuth2orize(Node.js)。這些服務支持OAuth2和OpenID Connect，它們是用于授權和身份驗證的基礎，行業標準協議。

實施身份驗證檢查應在API網關內部終止?？梢栽贏PI網關或微服務中實現授權。為了能夠進行廣泛的特定于應用程序的授權檢查，應該在特定的微服務中處理授權。這可以通過將JWT與請求一起傳遞來完成。這樣，域對象的特定于應用程序的授權就不會泄漏到API網關。