在使用oauth2通过IdP对其用户进行身份验证的Web应用程序中，用于实现用户权限（客户端和服务器端）的更多标准/推荐选项是什么？
通过“用户权限”，我指的是允许或不允许用户在应用程序内部执行的操作。例如，假设应用程序有一个“ admin”页面，用于管理应用程序的某些设置，只允许特定用户输入。其中一些用户仅被允许查看当前设置，而其他用户也被允许更改设置（可能只有其中一些）。
据我所知，oauth2中的“作用域”的概念可能可以用于实现这一要求，例如，仅允许查看“ admin”页面的用户将具有app:admin:view范围，而同时还可以编辑设置的用户将具有app:admin:some-setting:edit范围。但是，似乎在大多数大型身份提供者服务中，管理这些范围以及将其分配给用户的任务将是非常繁琐的。
这将是一个好的解决方案吗？如果是这样，是否有任何产品/服务可以与oauth2 IdP集成，并有助于更轻松地管理权限及其向用户的分配（例如，具有直观的UI）？如果没有，是否有建立的方法来处理这种情况？
我不会为此目的使用OAuth2 scopes。原因是OAuth2范围是为了限制application对用户resource的作用，而不是为了限制user在application中的作用。
例如，如果我编写了一个Web应用程序，向用户显示他们在Google Docs中使用的语言，则它需要Google委派的特权才能读取用户的Google Docs，但例如不需要读取他们的日历。因此，该应用程序将从Google获得的OAuth2令牌，该令牌scoped具有read-Docs特权，但没有read-calendar特权或任何其他不必要的特权。
使用范围来携带有关用户权限（而不是应用程序权限）的信息的具体缺点是，如果您要实现上述类似的功能，则应用程序可以对应用程序中的用户资源进行不同级别的访问，尝试以多种方式同时使用OAuth2范围可能会造成混淆。如果您想通过API向您的客户公开应用程序中的功能以集成到他们自己的应用程序中，那么这可能会成为问题。
您提到您正在使用OAuth2进行身份验证。 OAuth2用于委派授权not for authentication。 OAuth2访问令牌do not represent authenticated users。OpenId ConnectID令牌可以。
我喜欢使用AWS Cognito进行身份验证。它为您跟踪用户，因此您不需要用户数据库，并处理对它们的身份验证。对于跟踪不同类型用户的用例，可以使用Cognito Groups。 Here是带有示例的博客文章。
基本上，您将从Cognito获得ID令牌，并且您的客户端或服务器可以读取ID令牌以找出用户的组（管理员，常规用户等），并采取相应的措施。 Here是从令牌读取组的示例。