Profile Service
当创建令牌或者请求像Userinfo这种端点时，IdentityServer通常会需要用户的标识信息（identity information），默认情况下，IdentityServer只能从认证（authentication）Cookie中保存的claims中获取这些信息。
将用户的所有可用的信息都保存到Cookie中很显然是不现实的，也是一种不好的实践，所以，IdentityServer定义了一个可扩展的点，这个点（接口）允许动态的加载用户的Claim，这个点（接口）就是IProfileService。开发人员通常实现此接口来访问包含用户数据（claims）的自定义数据库或API。
IProfileService APIs
GetProfileDataAsync
开发者如果实现该接口方法，这个方法应该用来加载用户的claims。这个方法需要一个ProfileDataRequestContext实例作为参数。
IsActiveAsync
开发者如果实现该接口方法，这个方法用来指示当前用户是否能够获取到token，它需要一个IsActiveContext的实例作为参数
ProfileDataRequestContext
它为用户的声明（claims）建模，是用户声明的媒介物（承载体），它包含了以下属性：
Subject
ClaimsPrincipal类型，用来表示用户。
Client
Client类型，表示客户端（第三方）。
RequestedClaimTypes
IEnumerable<string>类型，用来表示请求的Claims类型。
Caller
string类型，用来表示被请求的Claims中上下文（Context）的标识符（例如IdentityToken，AccessToken,用户端点（userinfo endpoint）），IdentityServerConstants.ProfileDataCallers这个静态类声明的常量中包含了关于这方面的信息。
IssuedClaims
List<Claim>类型，这个列表是一个公共的属性，将会被返回，由自定义的IProfileService 实现（中的方法）进行填充。
AddRequestedClaims
它作为ProfileDataRequestContext 的扩展方法，用来填充IssedClaims这个列表属性，但是会首先利用RequestedClaimTypes这个列表属性里面的值过滤一下，也就是说会根据/基于RequestedClaimTypes里面的值返回相应的值。
Requested scopes and claims mapping 请求的scopes和声明之间的映射
在客户端的Scopes中声明的关于用户的信息会被放到token中返回到客户端。GetProfileDataAsync方法负责根据ProfileDataRequestContext中的RequestedClaimTypes属性来返回用户的信息。
而RequestedClaimTypes的填充（它是一个列表）是基于Resource（它为Scope进行了建模）中定义的Claims。如果请求的Scope中包含了IdentityResource，那么RequestedClaimTypes的填充是由IdentityResource中定义的Claims进行填充，如果请求的Scope中包含的是ApiResource，那么RequestedClaimTypes的填充是由ApiResource中定义的Scope进行填充的（由于默认情况如果构造ApiResource的时候没有制定Scopes这个属性的值，那么这个ApiResource内部会利用构造函数传入的name和displayname创建一个Scope）。
IsActiveContext
它建模请求已确定当前用户是否能够被允许获得令牌（token）。它包含以下属性:
Subject
ClaimsPrincipal类型，建模了当前用户，概念同ProfileDataRequestContext中的同名属性。
Client
Client类型，概念同ProfileDataRequestContext中的同名属性
Caller
String类型，概念通ProfileDataRequestContext中的同名属性
IsActive
boolean类型，它应该在IProfileService的实现中被赋值，已确定用户是否可以被允许获得token