Oauth2、范围和用户角色

Posted 2023-02-27

【中文标题】Oauth2、范围和用户角色

【英文标题】：Oauth2, scopes and user roles

【发布时间】：2018-07-12 21:19:03

【问题描述】：

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

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

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

我认为应该发生的事情如下：

Bob 进行身份验证。 Bob 的角色在他的身份验证完成后进行查找。他的“管理员”角色附加了“is_admin”范围。 Bob 请求一个访问令牌，其中包含从他的各个角色收集的所有范围 Bob 会自动获得访问令牌的这些范围

是否由我的调用应用程序强制仅发送请求 Bobs 需要的范围？还是在范围方面我缺少什么？

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

【问题讨论】：

对于那些因为需要知道有哪些范围而在这里磕磕绊绊的人：developers.google.com/identity/protocols/oauth2/scopes

【参考方案1】：

在OAuth2中，有以下角色：

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

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

在您的描述中，缺少客户端应用程序。假设它是您的 API 的前端应用程序。它需要一个范围为admin-user-scope 或regular-user-scope 的访问令牌。因此它将用户（资源所有者）重定向到 Auth 提供者，同时请求两个范围。

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

客户端应用程序在重定向 URI 中接收具有范围的访问令牌（或授权）。如果授予的范围与请求的范围不同，则身份验证提供程序会发送一个授予范围的列表（scope URL 参数）以及访问令牌，以便客​​户端应用程序知道它可以使用访问令牌执行哪些操作。

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

【讨论】：

我想我明白了。用户可以访问 a、b、c、d，但他可能只在进行身份验证时要求访问 a、b、c（例如，通过身份验证码请求）。 Auth 提供者只会响应用户要求的内容，而不是他的整个集合。如果 Auth 提供者发现用户对请求的范围没有权限（在我的情况下，不是特定角色），它还可以减少它返回的内容。一旦通过身份验证，用户只能获得一个访问代码，并附上所要求的（可能减少的）范围。这是一个正确的总结吗？

假设授权范围从 Auth Provider 返回到令牌中的客户端应用程序，以某种方式手动更改（MITM 或其他方式），并且添加了一个范围，如“管理员用户范围”。当客户端应用程序尝试使用此令牌从资源服务器获取资源时会发生什么，该资源服务器仅受管理员保护？

@ilans 除非 MITM 操作员知道用于生成访问令牌的私钥，否则他们无法在访问令牌不失效的情况下对其进行调整——换句话说，不仅 admin-user-scope不被接受，令牌本身将被拒绝，希望导致 401-未经授权的异常。

“身份验证提供者”和“资源服务器”在同一台服务器上运行是否常见？据我了解，“身份验证提供者”的工作是进行权限到范围的映射（我在这里将其命名为“权限”，以免将其与您在上面解释的 OAuth“角色”定义混淆，它可能是例如 LDAP 组），因此它需要对存在的范围有所了解。因此，这两个 OAuth 角色“身份验证提供者”和“资源服务器”之间存在依赖关系，因此拥有一起部署/更新的共享逻辑是有意义的。

范围、角色和用户之间的映射特定于身份验证提供程序的预期用途，标准没有提及对其进行描述。例如，角色“Google Drive 用户”可以启用对用户的 Google Drive 进行读取和写入的范围。资源服务器应该理解与其使用的身份验证提供者相同的一组范围和角色。所以是的，如果任何一方的范围或角色发生变化，另一个模块也需要更新。