目前，我的应用程序正在根据角色和权限验证用户的访问权限。例如，如果用户是管理员，则他拥有所有权限。
但是，现在我正在实施OAuth 2.0和OpenIdConnect，用于Web应用程序和REST API的单点登录和基于令牌的身份验证。
OAuth 2.0 和 Open id 连接严重依赖范围进行访问控制。诸如account.write account.read account.delete之类的范围与权限"CanCreateAccount"CanReadAccount"CanDeleteAccounts"CanAssignRolesToPermissions"非常相似。
我不明白两者有什么区别。这种分离强制我的应用程序在访问 REST API 时检查客户端的范围，并单独检查用户的权限。我相信这会导致代码重复。
我认为 OAuth 2.0 范围和应用程序权限相同是否正确？如果这是真的，那么我是否应该在整个应用程序中坚持使用范围，而不是维护单独的应用程序权限？
例如，当前为用户分配了一个角色，并且角色具有权限。如果我用范围替换权限，那么我就不必复制客户端/用户范围/权限检查功能。
您可能会想为什么不将范围替换为权限。这是因为我想坚持 OAuth 2.0 规范，并且在整个规范中使用范围。
Scopes是每Client app，而permissions是每user。换句话说，一个客户端应用可以具有访问某些 API 的范围，但此客户端应用的用户在此 API 中具有不同的权限(基于其角色)。应用程序不应检查作用域。IdentityServer(我看到您已将其用作标签，因此我建议您将其用作OAuth身份验证器)将拒绝没有所需范围的客户端。你的应用必须仅检查用户权限。
我认为 OAuth 2.0 范围和应用程序权限相同是否正确？
从技术上讲，这是不正确的。
OAuth 2.0范围不是应用程序权限。它们允许客户端应用程序代表用户访问资源。如果客户端应用程序已被授予资源的作用域 X，则仅当用户具有相应的权限时，才允许它访问该资源。
换句话说，必须将应用的范围与用户的权限一起检查。
若要了解详细信息，请查看这篇关于权限、特权和范围之间区别的文章。
您可以阅读这篇优秀的帖子或在同一帖子中观看视频，以清楚地了解范围、权限和特权。