引言

通常，服務所公開的資源和 API 必須僅限受信任的特定用戶和客戶端訪問。那進行 API 級別信任決策的第一步就是身份認證——確定用戶身份是否可靠。

在微服務場景中，身份認證通常統(tǒng)一處理。一般有兩種實現(xiàn)形式：

基于API 網(wǎng)關中心化認證：要求客戶端必須都通過網(wǎng)關訪問微服務。（這就要求提供一種安全機制來認證請求是來自于網(wǎng)關。）

?

基于安全令牌服務（STS）認證：所有的客戶端先從STS獲取令牌，然后請求時攜帶令牌完成認證。

?

Identity Service就是使用第二種身份認證方式。

服務簡介?

Identity microservice 主要用于統(tǒng)一的身份認證和授權，為其他服務提供支撐。

提到認證，大家最熟悉不過的當屬Cookie認證了，它也是目前使用最多的認證方式。但Cookie認證也有其局限性：不支持跨域、移動端不友好等。而從當前的架構來看，需要支持移動端、Web端、微服務間的交叉認證授權，所以傳統(tǒng)的基于Cookie的本地認證方案就行不通了。我們就需要使用遠程認證的方式來提供統(tǒng)一的認證授權機制。
而遠程認證方式當屬：OAuth2.0和OpenID?Connect了。借助OAuth2.0和OpenID Connect即可實現(xiàn)類似下圖的認證體系：

而如何實現(xiàn)呢，借助：

ASP.NET Core Identity

IdentityServer4

基于Cookie的認證和基于Token的認證的差別如下所示：

?

架構模式?

?從目錄結構可以看出它是一套MVC單層架構的網(wǎng)站。我們可以單獨進行運行和調(diào)試，也可以把它放進自己的項目中。

?

主要依賴：

1、HealthCheck 健康檢查

2、WebHost

3、Entity Framework

4、Autofac

5、IdentityServer4

6、其中IdentityServer4.AspNetIdentity又用到了ASP.NET Core Identity?

啟動流程?

?Program.cs

? ?Main函數(shù)：

BuildWebHost函數(shù)：

其中有一個UseHealthChecks，這是一個對項目健康的檢查。

健康檢查,其實這個名稱已經(jīng)很明確了,它是檢查你的應用程序是否健康運行的一種方式。隨著當前各類項目越來越多的應用程序正在轉向微

服務式架構，健康檢查就變得尤為關鍵。雖然微服務體系結構具有許多好處，但其中一個缺點就是為了確保所有這些服務都正常運行的操作開銷

更高。你不在是監(jiān)視一個龐大的整體項目的健康狀況，而是需要監(jiān)控許多不同服務的狀態(tài)，甚至這些服務通常只負責一件事情。健康檢查(Heatlh

?Checks)通常與一些服務發(fā)現(xiàn)工具結合使用，如Consul? ，來監(jiān)控您的微服務器，來觀測您的服務是否健康運行。

? ?健康檢查有很多種不同的方法，但最常見的方法是將HTTP端點暴露給專門用于健康檢查的應用程序。一般來說,如果一切情況都很好，你的服

務將返回200的狀態(tài)碼,然而任何非200的代碼則意味著出現(xiàn)問題。例如，如果發(fā)生錯誤，你可能會返回500以及一些出錯的JSON信息。

ASP.NET Core Identity && IdentityServer4簡介??

ASP.NET Core Identity用于構建ASP.NET Core Web應用程序的成員資格系統(tǒng)，包括成員資格，登錄和用戶數(shù)據(jù)（包括登錄信息、角色和聲明）。
ASP.NET Core Identity封裝了User、Role、Claim等身份信息，便于我們快速完成登錄功能的實現(xiàn)，并且支持第三方登錄（Google、Facebook、QQ、Weixin等，支持開箱即用[第三方身份提供商列表]），以及雙重驗證，同時內(nèi)置支持Bearer 認證（令牌認證）。

雖然ASP.NET Core Identity已經(jīng)完成了絕大多數(shù)的功能，且支持第三方登錄（第三方為其用戶頒發(fā)令牌），但若要為本地用戶頒發(fā)令牌，則需要自己實現(xiàn)令牌的頒發(fā)和驗證邏輯。換句話說，我們需要自行實現(xiàn)OpenId Connect協(xié)議。

OpenID Connect 1.0 是基于OAuth 2.0協(xié)議之上的簡單身份層，它允許客戶端根據(jù)授權服務器的認證結果最終確認終端用戶的身份，以及獲取基本的用戶信息。

而IdentityServer4就是為ASP.NET Core量身定制的實現(xiàn)了OpenId Connect和OAuth2.0協(xié)議的認證授權中間件。IdentityServer4在ASP.NET Core Identity的基礎上，提供令牌的頒發(fā)驗證等。

相關知識：

OAuth 2.0 簡介

OpenID Connect 簡介

Identity Server 4

認證流程?

?在ASP.NET Core中使用的是基于申明（Claim）的認證，而什么是申明（Cliam）呢？

Claim 是關于一個人或組織的某個主題的陳述，比如：一個人的名稱，角色，個人喜好，種族，特權，社團，能力等等。它本質(zhì)上就是一個鍵值對，是一種非常通用的保存用戶信息的方式，可以很容易的將認證和授權分離開來，前者用來表示用戶是/不是什么，后者用來表示用戶能/不能做什么。在認證階段我們通過用戶信息獲取到用戶的Claims，而授權便是對這些的Claims的驗證，如：是否擁有Admin的角色，姓名是否叫XXX等等。

認證主要與以下幾個核心對象打交道：

Claim（身份信息）

ClaimsIdentity（身份證）

ClaimsPrincipal （身份證持有者）

AuthorizationToken （授權令牌）

IAuthenticationScheme（認證方案）

IAuthenticationHandler（與認證方案對應的認證處理器）

IAuthenticationService （向外提供統(tǒng)一的認證服務接口）

那其認證流程是怎樣的呢？

1、用戶打開登錄界面，輸入用戶名密碼先行登錄，服務端先行校驗用戶名密碼是否有效，有效則返回用戶實例（User）。

2、這時進入認證準備階段，根據(jù)用戶實例攜帶的身份信息（Claim），創(chuàng)建身份證（ClaimsIdentity），然后將身份證交給身份證持有者（ClaimsPrincipal）持有。

3、接下來進入真正的認證階段，根據(jù)配置的認證方案（IAuthenticationScheme），使用相對應的認證處理器（IAuthenticationHandler）進行認證 。認證成功后發(fā)放授權令牌（AuthorizationToken）。該授權令牌包含后續(xù)授權階段需要的全部信息。

授權流程?

?授權就是對于用戶身份信息（Claims）的驗證，，授權又分以下幾種種：

基于Role的授權

基于Scheme的授權

基于Policy的授權

授權主要與以下幾個核心對象打交道：

IAuthorizationRequirement（授權條件）

IAuthorizationService（授權服務）

AuthorizationPolicy（授權策略）

IAuthorizationHandler （授權處理器）

AuthorizationResult（授權結果）

那授權流程是怎樣的呢？

當收到授權請求后，由授權服務（IAuthorizationService）根據(jù)資源上指定的授權策略（AuthorizationPolicy）中包含的授權條件（IAuthorizationRequirement），找到相對應的授權處理器（IAuthorizationHandler ）來判斷授權令牌中包含的身份信息是否滿足授權條件，并返回授權結果。

中間件集成?

?回過頭來我們再來刷一遍startup代碼中是怎么集成進Identity service的。

1. 首先是映射自定義擴展的User和Role

// 映射自定義的User，Roleservices.AddIdentity<ApplicationUser, IdentityRole>().AddEntityFrameworkStores<ApplicationDbContext>()//配置使用EF持久化存儲.AddDefaultTokenProviders();//配置默認的TokenProvider用于變更密碼和修改email時生成Token

?2. 配置IdentityServer服務

使用AddConfigurationStore和AddOperationalStore擴展方法就是用來來指定配置數(shù)據(jù)和操作數(shù)據(jù)基于EF進行持久化。

3. 添加IdentityServer中間件

app.UseIdentityServer();?

4. 預置種子數(shù)據(jù)

需要預置Client和Resource寫在Config.cs文件中，他們又是中main函數(shù)中被MigrateDbContext使用的。

• GetClients

• IdentityResources

身份資源是用戶ID、姓名或電子郵件地址等數(shù)據(jù)

• ApiResources

5. 遷移數(shù)據(jù)庫上下文

IdentityServer為配置數(shù)據(jù)和操作數(shù)據(jù)分別定義了DBContext用于持久化，配置數(shù)據(jù)對應ConfigurationDbContext，操作數(shù)據(jù)對應PersistedGrantDbContext。詳細看main函數(shù)。??

這篇文章使用了園子里『___知多少』文章對不少內(nèi)容，表示感謝，原文鏈接eShopOnContainers 知多少[3]：Identity microservice。

相關文章：

• eShopOnContainers 看微服務 ①：總體概覽

• eShopOnContainers 看微服務 ②：配置 啟動
  

• eShopOnContainers 知多少[1]：總體概覽

• eShopOnContainers 知多少[2]：Run起來
  

• eShopOnContainers 知多少[3]：Identity Microservice

• eShopOnContainers 知多少[4]：Catalog microservice

• Catalog Service - 解析微軟微服務架構eShopOnContainers（三）
  

• eShopOnContainers 知多少[5]：EventBus With RabbitMQ

• EventBus In eShop -- 解析微軟微服務架構eShopOnContainers（四）
  

• eShopOnContainers 是一個基于微服務的.NET Core示例框架

原文地址：https://www.cnblogs.com/tianyamoon/p/10081277.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的eShopOnContainers 看微服务③：Identity Service的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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