您无需使用细粒度安全性声明。身份服务器的主要目的是进行身份验证,并生成令牌,以便客户端可以向其他服务证明其身份。使用它来进行身份验证,而不是授权。
在Web API服务中,您可以拥有自己的授权数据库,其中包含用户,角色和特权,以便此信息不会由声明表示,而是存储在此数据库中。通过这种方式,您的应用程序可以处理有关授权的所有知识。
最后一步是将通过外部身份验证服务进行身份验证的每个用户映射到Web API授权数据库中的用户。
你还记得你是如何登录Stack Overflow的吗?我这样做了,我已将两个不同的Google帐户映射到我的SO用户帐户。我可以使用其中任何一个Google帐户登录SO。因此,SO不负责检查我是谁(身份验证),但一旦从外部服务收到令牌,它就确定我是谁,它可以决定我能做什么(授权)。
这是最灵活的工作方式,不会产生大量索赔。这不是索赔的目的。我记得有人将索赔与驾驶执照进行比较:它们非常相似,因为它是由第三方创建的,用于提供有关某人的信息。在现实生活中租车 - 汽车不必检查该人是否知道如何开车,因为他们可以向他询问他的驾驶执照(这就像是索赔)但是,除了有这些信息,他们可以根据自己的标准决定租车或不租车(如应用授权)。
将外部身份验证映射到应用程序用户的一个优点是,您可以轻松更改身份验证提供程序,或使用diffente身份验也许你也可以在声明中使用一些信息,比如电子邮件帐户,但是你不依赖于authroization的声明。
使用IndentityServer后,回答很简单。 IdentityServer主要角色是身份验证/令牌生成。 对于身份验证,应用程序重定向到IdentityServer。 IdentityServer将令牌(标识,访问)返回给客户端。该令牌使用HTML标头(承载令牌)发送到API。 在API方面,OWIN框架需要用于令牌验证的过滤器。过滤器使用“Thinktecture.IdentityServer3.AccessTokenValidation”实现。资源管理器使用过滤器来检查访问令牌是否允许使用特定API。
如何实现细粒度安全性是一个问题。问题是令牌的大小(令牌是每次调用WebAPI的一部分)。 将资源管理器与应用程序混合是不对的。但是对于细粒度的安全性,我相信这是我们唯一的选择。
外部提供商也只能返回那里可用的用户声明(谷歌,脸书等)。在页面上的文档中非常精确地解释了外部机制如何工作的详细描述 leastprivilege