然后需要添加资源和客户端, 按照官方文档的做法, 我添加一个Config类:这里我首先添加了一个GetUsers()方法, 里面有两个最终用户.注意TestUser的SubjectId属性的值, 在这个Identity Provider里面必须是唯一的.每个用户下面还有个Claims属性, claims里面都是代表用户的一些信息.但是如何让这些claims通过Identity Token返回来呢?Claims 与 Scope 是紧密相连的, 是多对一的. 下面我建立一个方法来返回Scope:在这里IdentityResource映射于那些关于用户信息的scope, 后边还要介绍ApiResource, 它映射于API资源的scopes. IdentityResource就是一些关于用户身份的数据, 例如user ID, name, email等等. 每个Identity Resource都有一个唯一的名称, 你可以为它赋一些claims, 然后这些claims就会包含在该用户的Identity Token里面(这只是一种情况), 客户端需要使用scope参数来请求访问某个identity resource.OpenID Connect协议里的scopes可以理解为一组预定义的claims的简称.OpenID Connect预定义了几组标准的scopes 或者叫 identity resources:openid, 这个是必须的. 它会为用户提供一个唯一的ID, 也叫做subject id. 它的出现也就是告诉授权服务器客户端发出的是OpenID Connect 请求. 它同时也要求返回ID Token. 如果 response_type 含有 token (指的是Access Token), 那么ID Token在授权的响应里和Access Token一同返回; 如果response_type 包含 code (指授权码), 那么ID Token会作为Token端点响应的一部分返回.profile, 这个是可选的. 这个scope请求访问的是最终用户的个人资料, 但是不包括email, address和phone, 它包括的claims有:name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, 和updated_at.email, 这个是可选的. 它包括email和email_verified两个claims.address, 这个是可选的. 它只有address一个claim.phone, 这个是可选的. 它包括phone_number和phone_number_verified两个claims.其中通过profile, email, address, phone这四个scope请求的claims, 如果请求的response_type的值包含token(指的是access token), 那么这些claims是从用户信息端点(UserInfo Endpoint)返回的. 而如果response_type不包含Access Token, 那么这些claims是在ID Token里面返回.Identity Server 4的IdentityResources类里面包含着上述这5个预定义的scopes.所以上面方法里TestUser的given_name和family_name将会在ID_Token里面返回.最后, 还需要定义客户端:暂时它还只是返回一个空的集合.这个Config类先到这, 现在还需要再修改一下Startup里的ConfigureServices方法, 把上面Config里面的配置都加进去:然后修改Startup里的Configure方法, 把IdentityServer添加到ASP.NET Core的管道里:启用TLS(SSL)我直接修改的launchSettings.json文件, 只保留了这一部分.然后运行程序, 访问该网址: https://localhost:5001/.well-known/openid-configuration, 会得到以下画面就说明Identity Server 4配置成功了:为Identity Server 4 添加UIIdentity Server 4 的UI可以在这里找到: https://github.com/IdentityServer/IdentityServer4.Quickstart.UI根据文档描述, 在Dave.IdentityProvider项目目录下打开Powershell执行这句话即可安装UI:iex ((New-Object System.Net.WebClient).DownloadString(https://raw.githubusercontent.com/IdentityServer/IdentityServer4.Quickstart.UI/release/get.ps1))安装好之后可以看到项目文件的变化:但是由于这套UI使用了ASP.NET Core MVC, 所以我还需要再配置一些东西.在Startup的ConfigureServices里, 注册MVC:在Startup的Configure里, 在管道里使用静态文件和MVC:再次运行程序, 首页如下:点击discovery document, 它就是我之前打开的那个页面.ASP.NET Core MVC 作为客户端首先考虑ASP.NET Core MVC 作为客户端应用的情况.ASP.NET Core MVC是机密客户端(Confidential Client), 它是传统的服务器端Web应用.它需要长时间访问(long-lived access), 所以需要refresh token. 那么它可以使用Authorization Code Flow或Hybrid Flow.在这里Hybrid Flow是相对高级一些的, 它可以让客户端首先从授权端点获得一个ID Token并通过浏览器(front-channel)传递过来, 这样我们就可以验证这个ID Token. 如果验证成功然后, 客户端再打开一个后端通道(back-channel), 从Token端点获取Access Token.下面是OpenID Connect官方文档给出的一个身份认证请求的例子.第一行的URI: /authorize 就是授权端点(Authorization Endpoint), 它位于身份提供商(Identity provider, IDP)那里. 这个URI可以从前面介绍的discovery document里面找到.第二行response_typecode id_token, 它决定了采取了哪一种Hybrid流程(参考上面那三个图).第三行 client_idxxxx, 这是客户端的身份标识.第四行 redirect_urihttps...., 这是客户端那里的重定向端点(Redirection Endpoint).第五行 scopeopenid profile email, 这就是客户端所请求的scopes.再看一遍这张图:为什么要返回两次ID Token呢? 这是因为第(4)步里面请求Token的时候要求客户端身份认证, 这时请求Token的时候需要提供Authorization Code, Client ID和 Client Secret, 这些secret并不暴露给外界, 这些东西是由客户端服务器通过后端通道传递给Token端点的. 而第一次获得的ID Token是从前端通道(浏览器)返回的.当这个ID Token被验证通过之后, 也就证明了当前用户到底是谁.下面简单对比一下前端和后端通道: