引言
通常，服务所公开的资源和 API 必须仅限受信任的特定用户和客户端访问。那进行 API 级别信任决策的第一步就是身份认证——确定用户身份是否可靠。
在微服务场景中，身份认证通常统一处理。一般有两种实现形式：
-
基于API 网关中心化认证：要求客户端必须都通过网关访问微服务。（这就要求提供一种安全机制来认证请求是来自于网关。）
-
基于安全令牌服务（STS）认证：所有的客户端先从STS获取令牌，然后请求时携带令牌完成认证。
Identity Service就是使用第二种身份认证方式。
服务简介
Identity microservice 主要用于统一的身份认证和授权，为其他服务提供支撑。
提到认证，大家最熟悉不过的当属Cookie认证了，它也是目前使用最多的认证方式。但Cookie认证也有其局限性：不支持跨域、移动端不友好等。而从当前的架构来看，需要支持移动端、Web端、微服务间的交叉认证授权，所以传统的基于Cookie的本地认证方案就行不通了。我们就需要使用远程认证的方式来提供统一的认证授权机制。
而远程认证方式当属：OAuth2.0和OpenID Connect了。借助OAuth2.0和OpenID Connect即可实现类似下图的认证体系：
而如何实现呢，借助：
- ASP.NET Core Identity
- IdentityServer4
基于Cookie的认证和基于Token的认证的差别如下所示：
架构模式
从目录结构可以看出它是一套MVC单层架构的网站。我们可以单独进行运行和调试，也可以把它放进自己的项目中。
主要依赖：
1、HealthCheck 健康检查
2、WebHost
3、Entity Framework
4、Autofac
6、其中IdentityServer4.AspNetIdentity又用到了ASP.NET Core Identity
启动流程
Program.cs
Main函数：
View CodeBuildWebHost函数：
public static IWebHost BuildWebHost(string[] args) => WebHost.CreateDefaultBuilder(args) .UseKestrel()//使用Kestrel作为的web服务器 .UseHealthChecks("/hc")//健康检查 .UseContentRoot(Directory.GetCurrentDirectory())//将当前项目的根目录作为ContentRoot目录 .UseIISIntegration()//使用IIS .UseStartup<Startup>()//使用startup类 .ConfigureAppConfiguration((builderContext, config) => { var builtConfig = config.Build(); var configurationBuilder = new ConfigurationBuilder(); if (Convert.ToBoolean(builtConfig["UseVault"])) { configurationBuilder.AddAzureKeyVault( $"https://{builtConfig["Vault:Name"]}.vault.azure.net/", builtConfig["Vault:ClientId"], builtConfig["
