為什麼身份驗證在微服務的體系結構中佔據中心位置

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

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

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

身份驗證和授權之間有什麼區別？

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

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

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解釋中描述的流程實際上使用了一種受支援的授權型別，確切地說是授權碼授權型別。

透過此流程，將使用者重定向到身份伺服器，在該伺服器上處理身份驗證和授權。客戶端（請求使用者資訊的應用程式）獲得使用者對所需資訊的授權。這是透過配置正確的作用域來完成的。範圍類似於特定客戶端可以訪問的資料型別。範圍的示例是電子郵件和地址，分別類似於使用者的電子郵件地址和地址。

範圍是由應用程式在身份驗證過程中請求的。當用戶在身份伺服器上對自己進行身份驗證時，使用者也有可能為請求的資料授予應用程式授權。獲得授權後，資料將被新增到令牌的有效載荷中並傳遞給應用程式。

在身份伺服器中，可以保留與使用者連線的角色。可以為公司中的所有員工設定身份伺服器。這些員工根據他們在公司中的角色具有不同的角色。身份伺服器可以將分配的角色共享給令牌中的特定使用者。這樣，可以與使用中的應用程式共享。

特定於應用程式的授權邏輯應內建在哪裡？

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

實施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閘道器內部終止。可以在API閘道器或微服務中實現授權。為了能夠進行廣泛的特定於應用程式的授權檢查，應該在特定的微服務中處理授權。這可以透過將JWT與請求一起傳遞來完成。這樣，域物件的特定於應用程式的授權就不會洩漏到API閘道器。