目前我的应用程序正在根据角色和权限验证用户的访问权限。例如，如果用户是管理员，则他拥有所有权限。
然而，现在我正在实现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规范，而且作用域在整个规范中都有使用。
3条答案
按热度按时间ldxq2e6h1#
Scopes是每个Client app，而permissions是每个user。换句话说，一个客户端应用可以有一个范围访问某些API（s），但此客户端应用程序的用户在此API中将具有不同的权限（基于其角色）。您的应用程序不应检查作用域。IdentityServer（我看到您已将其用作标记，因此建议您将其用作OAuth验证器）将拒绝不具有所需作用域的客户端。您的应用必须仅检查用户权限。nfg76nw02#
我认为OAuth 2.0作用域和应用程序权限是相同的，对吗？
从技术上讲，这是不正确的。
OAuth 2.0作用域不是应用程序权限。它们允许应用程序代表用户访问资源。如果您的应用程序已被授予某个资源的作用域X，则仅当用户具有相应权限时，才允许其访问该资源。
换句话说，应用的作用域必须与用户权限一起检查。
要了解更多信息，请查看有关difference between permissions, privileges, and scopes的文章。
5hcedyr03#
你可以阅读this优秀的帖子或观看同一帖子中的视频，以清楚地了解范围，权限和特权。