Oauth2,范围和用户角色

时间:2018-02-02 11:17:14

标签: oauth-2.0

我在这里概念性地提出一个问题,因为我试图理解基于OAuth2的系统中范围和用户角色之间的关系。

在我实现API时,我希望通过使用资源上的作用域来限制对特定资源的访问。我理解使用访问令牌来请求资源,我相信我的理解是正确的,因为您在请求访问令牌时指定了范围。

我不完全确定的是,范围的限制将如何根据经过身份验证的用户所处的特定角色起作用。让我们假设Bob是管理员而Sue是普通用户。我们有一些受 is_admin 范围保护的资源。什么阻止Sue在她的访问令牌中请求(和接收) is_admin 范围?

思考应该发生的事情如下:

  • Bob认证。
  • 在身份验证完成后查找Bob的角色。他的"管理员"角色有" is_admin"适用范围。
  • Bob要求提供一个访问令牌,其中包含从各种角色中收集的所有范围
  • Bob会自动为其访问令牌提供这些范围

是否由我的通话应用程序强制执行仅询问Bobs需要的范围?或者是否有关于范围的遗漏?

有人可以用一些简单的例子来启发我吗?

1 个答案:

答案 0 :(得分:10)

OAuth2中,有以下角色:

  • 资源所有者 - 通常是某人
  • 验证提供程序 - OAuth2服务器
  • 资源服务器 - 需要访问令牌并验证其范围的API
  • 客户端应用程序 - 请求具有某些范围的访问令牌的应用程序。

要了解OAuth2,有必要将其视为从资源所有者到客户端应用程序的访问权限委派协议。因此主要用例是:客户端应用程序想要访问资源服务器。为此,客户端应用程序需要由Auth提供程序颁发​​并由资源所有者授权的访问令牌(由Auth提供程序进行身份验证)。

在您的说明中,缺少客户端应用程序。我们假设它是您API的前端应用程序。它需要具有范围admin-user-scoperegular-user-scope的访问令牌。因此,它将用户(资源所有者)重定向到Auth提供程序,请求两个范围。

Auth提供程序对用户进行身份验证,并要求他/她同意向客户端应用程序授予一些请求的作用域。 Auth提供程序may remove some scopes - 例如非管理员的admin-user-scope。 Auth提供程序可以为用户提供删除某些范围的可能性。

客户端应用程序在重定向URI中接收带有作用域的访问令牌(或授权)。如果授予的作用域与请求的作用域不同,则Auth提供程序会发送已授予作用域的列表(scope URL参数)以及访问令牌,以便客​​户端应用程序知道它可以使用访问令牌执行的操作。

然后客户端应用程序可以访问资源服务器,资源服务器确保提供的访问令牌包含所需的范围。资源服务器使用OAuth2 introspection endpoint来验证tokoen并获取其范围列表。

相关问题