entity-framework – IdentityServer 3 Asp.net身份：范围,声明

我试图总结我的发现,为我的问题找到一个基础.

> IdentityServer使用OpenID Connect发出令牌.颁发的令牌是ID令牌和访问令牌.
>使用OAuth 2.0流程向客户端请求令牌(如OpenID Connect协议所述).每个客户一个流程.
>在流程开始期间,客户端请求范围集合(至少“openid”,这是因为他必须声明已激活OpenID Connect流)
>客户可以询问他有权要求的所有范围.使用IdentityServer的Entity Framework插件,此信息包含在ClientScope表中.如果客户端请求他未被授权请求的范围,则流程将被中断.
>范围可能“包含”索赔.这意味着,如果范围包含一组声明,则每当向客户端颁发令牌时,此令牌也包含所有相应用户的声明.例如：让“角色”称为包含“角色”声明的范围.一旦客户端获得授权,收到的令牌将包含所有用户的角色(作为声明).
>如果获得授权,每个请求的范围都在名为“范围”的索赔中“翻译”.这意味着如果客户端请求例如定义的“api”范围,则生成的标识将至少具有值为“api”的称为“范围”的声明.

如果我写的所有内容都越来越不正确,我的问题就在这里：

>如何在asp.net身份表(即AspNetUserClaims)上定义的声明与IdentityServer连接.对于我所看到的,匹配是在名称上进行的.这个结论是否正确？换句话说,如果我的客户端必须收到“角色”声明(因为他已经要求“角色”范围),IdentityServer的“Asp.Net Identity”插件是否会释放为经过身份验证定义的“角色”声明用户？
>引用“EntityFramework”插件表,“ClientClaims”表的含义是什么？我无法理解索赔如何直接与客户联系……我缺少什么？
>让我们假设在我的资源服务器中,我有一个使用ResourceAuthorize属性保护的操作,如下所示：

[ResourceAuthorize(“Read”,“Orders”)]

在我的AuthorizationManager中,我检查是否存在声明“order_read”或声明“api”.这些是我的AuthorizationServer中定义的两个不同的范围,一个用于“订单阅读”,另一个用于完整的API访问.第一方可能会被第三方客户询问,而后者则不会.这是一个好习惯吗？
>我无法理解我的客户端应该用id_token做什么.我应该忽略这个问题,因为我正在使用js库OIDC令牌管理器吗？安全控件是否由此库执行？
>上一个问题：当我的应用程序提供访问令牌时,ClaimsIdentity是如何生成的？是否可以说它是在验证Identity Server上的令牌后生成的？这是否意味着IdentityServer将获取访问令牌并将其转换为一组声明？

谢谢你的澄清！

马尔科