如何在 oauth2 身份验证之上实现用户权限

Question

在使用 IdP 通过 IdP 对其用户进行身份验证的 Web 应用程序中，oauth2用于实现用户权限（客户端和服务器端）的更标准/推荐选项是什么？

通过“用户权限”，我指的是用户在应用程序中允许或不允许执行的操作。
例如，假设应用程序有一个“管理”页面，用于管理应用程序的某些设置，仅允许特定用户进入。其中一些用户仅被允许查看当前设置，而其他用户也被允许更改设置（可能只有其中一些）。

据我所知，oauth2 中“范围”的概念可能用于实现这样的要求，例如，仅被允许查看“管理”页面app:admin:view的用户将具有范围，而可以此外，编辑设置也会有一个app:admin:some-setting:edit范围。
但是，在大多数大型身份提供者服务中，管理这些范围并将它们分配给用户的任务似乎是一项相当乏味的任务。

这会是一个很好的解决方案吗？如果是这样，是否有任何产品/服务与 oauth2 IdP 集成并帮助更轻松地管理权限及其分配给用户（例如，具有漂亮直观的 UI）？如果没有，是否有任何既定方法处理此类情况？

Answer 1

范围

我不会为此目的使用OAuth2 范围。原因是 OAuth2 范围用于限制应用程序可以对用户资源执行的操作，而不是限制用户可以在应用程序中执行的操作。

例如，如果我编写了一个 Web 应用程序，向用户显示他们在其 Google 文档中使用的语言，则需要从 Google 委派的权限才能阅读用户的 Google 文档，而不是例如阅读他们的日历。因此，应用程序将从 Google 获得一个 OAuth2 令牌，该令牌的范围具有 read-Docs 权限，而不是 read-calendar 权限或任何其他不必要的权限。

使用范围来携带有关用户权限（而不是应用程序权限）的信息的具体缺点是，如果您想实现类似上面的内容，应用程序可以在应用程序中获得对用户资源的不同级别的访问权限，则可能是试图同时以多种方式使用 OAuth2 范围会令人困惑。如果您想通过 API 向客户公开应用程序中的功能以集成到他们自己的应用程序中，这可能会成为一个问题。

OAuth2 委托与 OpenID Connect 身份验证

您提到您正在使用 OAuth2 进行身份验证。OAuth2 用于委托授权，而不是用于身份验证。OAuth2 访问令牌不代表经过身份验证的用户。OpenId Connect ID 令牌可以。

AWS Cognito 用户组

我喜欢使用AWS Cognito进行身份验证。它为您跟踪您的用户，因此您不需要用户数据库，并处理对他们的身份验证。它与 Google 和 Facebook 等外部身份提供商集成。对于跟踪不同类型用户的用例，您可以使用 Cognito Groups。这是一篇带有示例的博客文章。

基本上，您将从 Cognito 获得一个 ID 令牌，您的客户端或您的服务器可以读取 ID 令牌以找出用户的组（管理员、普通用户等），并采取相应的行动。这是从令牌中读取组的示例。