Joh*_*ohn 5 security openid oauth-2.0 asp.net-identity identityserver4
目前，我的应用程序正在根据角色和权限验证用户的访问权限。例如，如果用户是admin，则他拥有所有权限。
但是，现在我正在为Web应用程序和REST API的单点登录和基于令牌的身份验证实现OAuth 2.0和OpenIdConnect。
OAuth 2.0和Open id connect严重依赖于范围进行访问控制。诸如account.write account.read account.delete之类的范围与权限“ CanCreateAccount”，“ CanReadAccount”，“ CanDeleteAccounts”，“ CanAssignRolesToPermissions”非常相似。
我不明白两者之间的区别。这种分离迫使我的应用程序在访问REST API时检查客户端的范围，并单独检查用户的权限。我相信这会导致代码重复。
我认为OAuth 2.0范围和应用程序权限相同是正确的吗？如果是这样，那么我是否应该坚持整个应用程序的作用域，而不是维护单独的应用程序权限？
例如，当前为用户分配了一个角色，并且该角色具有权限。如果我用范围替换权限，则不必重复客户端/用户范围/权限检查功能。
您可能在想为什么不使用权限替换作用域。那是因为我要坚持OAuth 2.0规范，并且在整个规范中都使用了范围。
m3n*_*ak3 10
Scopes是 per Client app，而permissionsper user。换句话说 - 一个客户端应用程序可以有一个范围来访问某些 API，但是这个客户端应用程序的用户将在这个 api 中拥有不同的权限（基于他们的角色）。您的应用程序不应检查范围。IdentityServer（我看到您已将其用作标记，因此我建议您将其用作 OAuth 身份验证器）将拒绝没有所需范围的客户端。您的应用程序必须只检查用户权限。
小智 9
我认为 OAuth 2.0 范围和应用程序权限相同吗？
从技术上讲，这是不正确的。
OAuth 2.0范围不是应用程序权限。它们允许客户端应用程序代表用户访问资源。如果您的客户端应用程序已被授予资源的范围 X，则仅当用户具有相应的权限时才允许访问该资源。
换句话说，您的应用程序的范围必须与用户的权限一起检查。
要了解更多信息，请查看这篇有关权限、特权和范围之间差异的文章。