OAuth范围和应用程序角色＆amp;权限

Question

目前，我的应用程序正在根据角色和权限验证用户的访问权限。例如，如果用户是管理员，那么他拥有所有权限。

但是，现在我正在为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规范，并且在整个规范中都使用了范围。

Answer 1

Scopes符合Client app，permissions符合user。换句话说 - 一个客户端应用程序可以有一个范围来访问某些API，但此客户端应用程序的用户将在此API中具有不同的权限（基于他们的角色）。您的应用程序不应检查范围。 IdentityServer（我发现您已将其用作标记，因此我建议您将其用作OAuth身份验证器）将拒绝没有所需范围的客户端。您的应用只能检查用户权限。