OAuth作用域以及应用程序角色和权限

7uhlpewt  于 2022-12-17  发布在  其他
关注(0)|答案(3)|浏览(157)

目前我的应用程序正在根据角色和权限验证用户的访问权限。例如,如果用户是管理员,则他拥有所有权限。
然而,现在我正在实现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规范,而且作用域在整个规范中都有使用。

ldxq2e6h

ldxq2e6h1#

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

nfg76nw0

nfg76nw02#

我认为OAuth 2.0作用域和应用程序权限是相同的,对吗?
从技术上讲,这是不正确的。
OAuth 2.0作用域不是应用程序权限。它们允许应用程序代表用户访问资源。如果您的应用程序已被授予某个资源的作用域X,则仅当用户具有相应权限时,才允许其访问该资源。
换句话说,应用的作用域必须与用户权限一起检查。
要了解更多信息,请查看有关difference between permissions, privileges, and scopes的文章。

5hcedyr0

5hcedyr03#

你可以阅读this优秀的帖子或观看同一帖子中的视频,以清楚地了解范围,权限和特权。

相关问题