理解声明

时间:2016-05-06 08:40:50

标签: oauth-2.0 claims-based-identity openid-connect identityserver3

我正在尝试使用OpenId Connect,OAuth2.0,安全令牌服务和声明。想象一下具有许多区域和不同功能的大型网站的场景,例如客户,订单,供应商,交货,退货等我的问题是 - 我会在令牌服务器上创建声明,如CanCreateCustomer,CanReadCustomer,CanUpdateCustomer,CanDeleteCustomer等,即有效CRUD声明每个主要区域/业务对象?这将导致数十个但更可能数百个索赔。或者我的理解是否很短暂?

4 个答案:

答案 0 :(得分:3)

因此,固定术语是指“范围”,而不是“声明”。范围是用于指定所请求的访问权限的标识符。声明是包含有关用户信息的名称/值对。

因此,具有良好作用域的示例为“ read_only”。声明的示例是“ email”:“ john.smith@example.com”。

您可以使用ID令牌(或JWT)发送声明,或者/并且可以通过userinfo端点(如果使用“ openid”范围)使声明可用。

您可以按服务细分作用域,并根据需要将其作为粒度。或将它们设为高级(读/写/管理)。我建议您有足够的范围来主动实现最低特权的安全原则(基本上是:为人们提供完成工作所需的一切)。如果您有很多范围,则可以使用名称空间。

答案 1 :(得分:2)

您的理解是正确的,但您在OAuth2.0范围(声明)中具有更大的灵活性

可以以任何方式配置这些范围,例如,在您的情况下,您可以创建组范围,例如

,而不是为每个主区域的每个CRUD操作创建单独的范围。
customer.read_write
order.read_write 

等等,您甚至可以通过创建功能级别范围(例如

)来提高一级
webportal.full_access
adminportal.full_access

然后在您的应用程序中,经过身份验证后,授权可以像

那样完成
ValidScopesIn({Scopes.WEBPORTAL_FULL_ACCESS, Scopes.CUSTOMER_READ_WRITE})
public void createCustomer(Customer customer) {
// your creation logic 
}

答案 2 :(得分:1)

我认为你的理解基本上是正确的。但是,如果我理解您正确描述的内容,那么似乎更多的是授权(OAuth)而不是身份验证(OIDC)问题,因此您可能会了解其他OAuth资源提供程序如何定义其范围(不是声明btw),例如GitHubSlack

答案 3 :(得分:1)

我会建议"范围"被配置为URI,以便不发生冲突。

作为example

-Jim