1

OAuth 2.0 协议提供用户的权限委托，以便第三方应用程序可以代表用户进行操作。在 OAuth 流程上执行此操作的典型方式是请求用户同意批准或拒绝对应用程序的访问（Okta 示例）。这是一个官方规范，描述了它在一般概念中的工作原理。

我正在寻找针对用户组（例如组织）执行相同流程的标准化方法。GitHub 以某种方式为组织做到了这一点，所以看起来组织只是代表一组用户帐户。这个问题有没有标准化的方法？

如果不是，也许有任何推荐的方法，它通常是如何在架构上完成的，或者可以适合 OAuth 2.0/OpenID Connect 协议。

在此处输入图像描述

4

3 回答 3

1

OAuth 2.0/OpenID Connect 协议不包括如何执行访问控制。

您可以在 OAuth 2.0/OpenID Connect 协议中传递OAuth 范围或使用 OIDC用户信息端点数据来允许资源服务器确定访问控制。

该领域的许多商业产品允许使用 LDAP 作为身份验证的后端，甚至可以将 LDAP 组转换为范围。

我会假设，但我不知道，GtHub 为组织和/或用户存储带有链接（如组）的数据。我知道GitHub使用 OAuth Scopes 公开了这一点。

哦，OAuth 规范位于：https ://oauth.net/2/ 但是如果您需要用户身份验证，那么您需要使用构建在 OAuth 2.0 之上的OpenID Connect 。请记住“ OAuth 2.0 不是身份验证协议”

-吉姆

于 2019-11-15T09:27:25.350 回答
1

您可以在同意屏幕上显示的内容存在限制，并且通常不支持动态计算的数据。

您应该能够表达您可以呈现给用户的高级范围。

就基于用户组织的授权而言，此处的声明缓存技术可能很有用： https ://authguidance.com/2017/10/03/api-tokens-claims/

即： * 使用 OAuth 进行用户识别和高级检查“然后根据您的后端数据进行真正的授权

于 2019-11-18T19:57:48.783 回答
0

我在这里做了一些假设，但我相信问题出在尝试同时验证两件事。

如果组织是您所需要的，那么继续创建一个流程来将组织验证为主体主体（通过有权访问它的用户），而不是实际验证用户本身。

一旦生成了访问令牌，您就不必再知道是哪个用户生成了它（或者至少，令牌本身不需要知道）。如果您的用户需要能够查看和/或撤销访问令牌，他们应该仍然能够这样做，因为他们可以访问您应用中的组织。

于 2021-04-14T20:47:03.630 回答