首页 > 解决方案 > 如何在 oauth2 身份验证之上实现用户权限

问题描述

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

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

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

那会是一个很好的解决方案吗?如果是这样,是否有任何产品/服务与 oauth2 IdP 集成并有助于更轻松地管理权限及其对用户的分配(例如,使用直观的 UI)?如果没有,是否有任何既定的方法来处理这种情况?

标签: securityoauth-2.0permissionsauthorizationuser-permissions

解决方案


范围

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

例如,如果我编写了一个 Web 应用程序,向用户展示他们在 Google Docs 中使用的语言,则它需要 Google 委派的权限才能读取用户的 Google Docs,但不需要读取他们的日历等。因此,应用程序将从 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 令牌以找出用户的组(管理员、普通用户等),并采取相应的行动。是从令牌中读取组的示例。


推荐阅读