OAuth授权范围和应用程序角色及权限

Question

目前我的应用程序基于角色和权限验证用户的访问。例如，如果用户是管理员，则具有所有权限。

然而，现在我正在实施OAuth 2.0和OpenIdConnect，为Web应用程序和REST API提供单点登录和令牌验证。

OAuth 2.0和OpenID Connect对于访问控制非常依赖于范围(scope)。诸如account.write、account.read和account.delete等范围(scope)非常类似于权限“CanCreateAccount”、“CanReadAccount”、“CanDeleteAccounts”、“CanAssignRolesToPermissions”。

我不明白两者之间的区别。这种分离迫使我的应用程序在访问REST API时检查客户端的范围，并单独检查用户的权限。我认为这导致了代码重复。

我想知道OAuth 2.0的范围和应用程序权限是否相同？如果是这样，那么我应该只坚持使用范围(scope)而不是维护单独的应用程序权限吗？

例如，当前用户被分配到一个角色中，而角色具有权限。如果我用范围(scope)替换权限，那么我就不必重复客户端/用户范围(scope)/权限检查功能。

你可能会想，为什么不将权限替换为范围(scope)。那是因为我想坚持使用OAuth 2.0规范，而范围(scope)在整个规范中都被使用。

- John

Answer 1

Scopes 是基于 Client app 的，而 permissions 是基于 user 的。换句话说 - 一个客户端应用程序可以拥有访问某些API的作用域(s)，但是该客户端应用程序的用户在该api中将具有不同的权限(基于他们的角色)。您的应用程序不应检查作用域。IdentityServer（我看到您已将其用作标记，因此建议您将其用作OAuth认证器）将拒绝没有所需范围(s)的客户端。您的应用程序只需检查用户权限。

- m3n7alsnak3

---

但是，如果我不检查API的范围，那么我如何限制客户端访问API的某些资源呢？例如，如果第三方客户端只有对帐户终端的只读访问权限，则API有责任拒绝任何客户端请求其他资源。 - John

我不认为这是一个边缘情况。根据我对OAuth的了解，作用域控制API资源的访问。参见Github和Slack API。它们似乎使用作用域来控制客户端对API资源的访问，类似于权限。但是，从Github.com上看，他们如何处理用户权限和API作用域并不清楚。 https://developer.github.com/apps/building-oauth-apps/scopes-for-oauth-apps/ - John

这正是我所说的。作用域用于控制客户端访问权限，而角色/权限用于控制用户访问权限。 - m3n7alsnak3

我猜你所说的服务是指受Identity Server保护的某个API。在这种情况下，请求将带有一个令牌，该令牌包含范围，并且该令牌由Identity Server发出。如果客户端请求的范围不允许他，则IDS将拒绝认证。然后，如果客户端获得了一些范围的令牌，但尝试访问需要不同范围的API，则API本身将拒绝请求。 - m3n7alsnak3

@m3n7alsnak3 所以，总结一下，资源服务器（API）必须检查两个方面：用户角色/权限 和 令牌范围，以便对每个API方法进行授权决策。我的理解正确吗？ - Ruslan Stelmachenko

Answer 2

我认为OAuth 2.0的作用域和应用程序权限是相同的，这种想法是错误的。

实际上，OAuth 2.0的范围并不等同于应用程序权限。它们允许客户端应用程序代表用户访问资源。如果您的客户端应用程序已被授予资源的范围X，则仅当用户具有相应特权时，它才允许访问该资源。

换句话说，必须同时检查您的应用程序的作用域和用户的特权。

要了解更多信息，请查看关于权限、特权和作用域之间区别的文章。

- Andrea Chiarelli

---

为了更清楚地区分：用户的权限是他们所能做的一切，而范围可以将其缩小。也许他们可以读写图片，但对于照片应用程序，他们只被授予只读权限。然后第三方只能读取，而用户本身还可以进行写入操作。 - Bernhard

Answer 3

你可以阅读this的优秀文章或在同一篇文章中观看视频，以清晰地了解作用域、权限和特权。

- SatishKG