我们正在开发AngularJS / SPA应用程序，例如500个表单，连接到ASPNET WebAPI。任何形式都有＆＃34;阅读＆＃34;，＆＃34;写＆＃34;，＆＃34;查询＆＃34;和＆＃34;额外的定制＆＃34;访问权限。访问权限可以在＆＃34;角色＆＃34;中组合在一起。每个用户都可以在特定表单上定义一个或多个角色和/或特定权限。
我使用OpenId Connect / Oauth2和基于令牌的身份验证/授权研究了新的身份安全框架。身份验证用作用户登录到内部/外部IdentityProvider（如果成功，则返回身份令牌）。在访问资源（Web API）之前，需要访问令牌。 我还在使用identityserver V3，它看起来不错。 对于身份验证过程（身份令牌），一切正常。 对于授权过程（访问令牌），我无法找到正确的实现细节。
这里的问题是： 1.）使用声明来定义安全性。如果每个用户有多个声明（细粒度的安全性，由用户声明定义），用户是否需要每次在调用资源之前询问IdentityProvider是否有访问令牌？ 每次访问资源时用户询问IdentityProvider的开销如何？ 是否允许用户仅发送身份令牌和资源，然后向身份管理员询问访问令牌（代表用户）？ 此外，为了优化访问框架，IdentityManager可以直接访问Provider数据库（而不是生成和验证令牌）。这在技术上意味着IdentityProvider和ResourceProvider紧密耦合。
2.。）如果未使用声明定义权限。只有身份令牌同时也是访问令牌。在应用程序中，有内部ResourceManager，它存储分配给身份用户的访问权限（基于角色，细粒度）。因此，ResourceManager以从身份令牌识别用户的方式充当过滤器，然后检查数据库的访问权限并确定用户是否可以使用资源。这意味着ResourceProvider是应用程序的一部分，IdentityProvider仅用于身份验证？这也适合＆＃34;现代＆＃34;应用程序安全系统的类型？
3。）混合选项。 IdentityProvider具有身份和角色声明。 ResourceProvider将角色和细粒度权限映射到Identity角色/用户。在这种情况下，我不知道外部提供商如何，例如Google / FB可以知道我们的应用需要什么类型的角色？
4。）使用外部身份提供者时，例如从访问权限的角度来看，Google声称通常可用于我们的应用程序（个人用途，例如姓名，电子邮件，年龄，出生日期等）？蜜蜂谷歌管理员（角色）并不意味着它也是我们的应用程序的管理员？
很抱歉很长的帖子:) RGDS， 弗伦克
答案 0 :(得分：1)
您无需使用细粒度安全声明。身份服务器的主要目的是进行身份验证，并生成令牌，以便客户端可以向其他服务证明其身份。使用它来进行身份验证，而不是授权。
在Web API服务中，您可以拥有自己的具有用户，角色和权限的授权数据库，以便此信息不会由声明表示，而是存储在此数据库中。通过这种方式，您的应用程序可以处理有关授权的所有知识。
最后一步是将由外部身份验证服务验证的每个用户映射到Web API授权数据库中的用户。
你还记得你是如何登录Stack Overflow的吗？我这样做了，我已将两个不同的Google帐户映射到我的SO用户帐户。我可以使用其中任何一个Google帐户登录SO。因此，SO不负责检查我是谁（身份验证），但一旦收到外部服务的令牌，它就确定我是谁，它可以决定我能做什么（授权）。
这是最灵活的工作方式，不会产生大量索赔。这不是索赔的目的。我记得有人将索赔与驾驶执照进行比较：它们非常相似，因为它是由第三方创建的，用于提供有关某人的信息。在现实生活中租车 - 汽车不必检查该人是否知道如何开车，因为他们可以向他询问他的驾驶执照（这就像是索赔）但是，除了有这些信息，他们可以根据自己的标准（如应用程序授权）决定租车或不租车。
将外部身份验证映射到应用程序用户的一个优点是您可以轻松更改身份验证提供程序，或使用diffente身份验证提供程序。也许你也可以使用索赔中的一些信息，比如电子邮件帐户，但你不依赖于autroroization的声明。
答案 1 :(得分：0)
使用IndentityServer后，回答很简单。 IdentityServer主要角色是身份验证/令牌生成。 对于身份验证，应用程序重定向到IdentityServer。 IdentityServer将令牌（标识，访问）返回给客户端。该令牌使用HTML标头（承载令牌）发送到API。 在API方面，OWIN框架需要用于令牌验证的过滤器。过滤器使用“Thinktecture.IdentityServer3.AccessTokenValidation”实现。资源管理器使用过滤器来检查访问令牌是否允许使用特定的API。
如何实现细粒度安全性是一个问题。问题是令牌的大小（令牌是每次调用WebAPI的一部分）。 将资源管理器与应用程序混合是不对的。但是对于细粒度的安全性，我相信这是我们唯一的选择。
外部提供商也只能返回那里可用的用户声明（谷歌，脸书等）。在页面上的文档中非常精确地解释了外部机制如何工作的详细描述 leastprivilege