Consent 确认
在授权请求期间，如果身份服务器需要用户同意，浏览器将被重定向到同意页面。也就是说，确认也算是IdentityServer中的一个动作。确认这个词直接翻译过来有一些古怪，既然大家都知道Consent就是确认的意思，下文都以Consent来指代确认。
Consent被用来允许终端用户将一些资源（例如identity 和 API）的访问权限授予客户端。这通常适用于一些第三方应用，并且可以在 client settings中对每个客户端进行这方面的设置。
Consent Page 确认页面
为了实现这个功能，必须在宿主程序上面提供一个确认页面， quickstart UI（identityerServer4提供的一个demo）有一个关于确认页面的基本实现。
一个确认页面通常来说会渲染如下信息：
- 当前用户的名称（displayname）
- 发出请求的客户端的名称（displayname）
- 客户端的logo
- 关于客户端更多信息的一个链接（link）
- 客户端想要请求的资源列表
此外，还有一些比如说允许用户点击“remembered”按钮以便相同应用下次不用重复这个步骤。
一旦用户做完了他该做的事儿（点击了同意），确认页面必须把这个确认消息通知给identityserver，然后浏览器会被跳转回authorization端点。
Authorization Context上下文
IdentityServer会将一个returnUrl参数（可通过user interaction options配置）传递到一个包含请求参数的确认页面中。这些参数为确认页面提供了上下文，并且这些上下文可以通过 interaction service进行读取。GetAuthorizationContextAsync 方法（在interaction service中定义）会返回一个AuthorizationRequest对象。
关于客户端或资源的其他详细信息可以使用IClientStore和IResourceStore接口获得。
Informing IdentityServer of the consent result通知IdentityServer确认结果
interaction service上的GrantConsentAsync API允许同意页面通知IdentitySeerver的同意结果（也可能是拒绝客户机访问）。
身份服务器将暂时保留确认的结果。这种持久性在默认情况下使用cookie，因为它需要持续足够长的时间才能将结果传递回授权端点。这种临时持久性与“记住我的确认”特性的持久性不同（它是授权端点，它为用户保留“记住我的确认”）。如果你希望在确认页面和授权重定向之间使用其他的持久性，那么你可以实现IMessageStore<ConsentResponse>，并注入DI。
Returning the user to the authorization endpoint将用户重定向到authorization端点
一旦确认页面将确认结果通知给IdentityServer，用户就能被重定向到returnUrl指定的页面上。你的确认页面应该通过检查是否有效来避免open redirected。这个工作是通过interaction service上面的IsValidReturnUrl来做的。或者，如果
GetAuthorizationContextAsync 返回一个不为空的结果，那么你也可以确定returnUrl是有效的。