用户组/组织的OAuth 2.0流程

Question

OAuth 2.0协议提供了用户的权限委派，以便第三方应用程序可以代表其运行。在OAuth流程上完成此操作的典型方式是请求用户同意批准或拒绝对该应用程序的访问（Okta example）。这是official spec，描述了其在一般概念中的工作原理。

我正在寻找标准化的方法来执行相同的流程，但要针对用户组（例如组织）。 GitHub以某种方式对组织进行了这种处理，因此看起来组织仅代表一组用户帐户。有没有解决此问题的标准化方法？

如果没有，也许有任何建议的方法来实现其典型的体系结构或使其适合OAuth 2.0 / OpenID Connect协议。

Answer 1

OAuth 2.0 / OpenID Connect协议未涵盖访问控制的执行方式。

您可以在OAuth 2.0 / OpenID Connect协议中传递OAuth Scopes或使用OIDC user info endpoint数据来允许资源服务器确定访问控制。

此区域内的许多商业产品都允许使用LDAP作为身份验证的后端，甚至可以将LDAP组转换为作用域。

我会假设，但我不知道，GtHub使用链接（如组）为组织和/或用户存储数据。我知道GitHub使用OAuth范围公开了此内容。

哦，OAuth规范位于：https://oauth.net/2/ 但是，如果您需要用户身份验证，则需要使用OpenID Connect，它是在OAuth 2.0的顶部构建的。 请记住，“ OAuth 2.0 is NOT an Authentication protocol”

-吉姆

Answer 2

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

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

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

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

Answer 3

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

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

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