如何将授权委托给外部 Auth 2.0 服务

Question

我正在开发一项服务，该服务提供支持OAuth 2.0 的不同服务的智能（希望）集成。我们工具的重点是改进团队工作流程，因此我们结合了Slack、GitHub、Asana（问题跟踪器）、Cezanne（人力资源工具）等。

我们有可与所有这些工具配合使用的 ui 和后端（用户已获得所有这些工具的授权，因此我需要访问和刷新令牌）。我们需要能够根据人在特定工具中的角色隐藏用户界面的不同部分。我们以GitHub 为例。用户可以是存储库所有者、贡献者、公司所有者（对于企业帐户）等，因此这些用户可能需要根据他们的权限使用不同的用户界面。

最初我对自己实现授权犹豫不决（另一个自定义授权系统是这个世界最不需要的东西），我想利用其他服务的授权机制并围绕它们创建一个轻量级包装器。起初这似乎是一个合理的想法，但我不知道如何实现它，谷歌也没有提供有价值的建议，这意味着：99.99% 我正在尝试做一些愚蠢的事情，00.01% 我正在尝试做一些罕见/创新的东西。

我希望利用OAuth 2.0，但它似乎不支持我们需要的东西。最接近的是范围，但它看起来与我们的场景不太相关。

我现在唯一的想法是创建我们自己的授权系统并使用逆向工程集成其他服务。所以我会使用 API 请求用户的 GitHub 帐户详细信息，并在我们的系统中适当地应用他的角色：存储库 A 的所有者、存储库 B 的贡献者、公司 C 的所有者等。我将不得不对每个角色的权限进行反向工程（即存储库所有者不能更改公司名称）。而且我们必须为每个服务保留用户角色：而不是典型的管理员/用户/经理/等。我们将获得：OwnerOfGitHubRepository（用于 repositoryA）、ManagerOfAsanaTeam（用于团队 B）等。

如果OAuth 2.0 服务有一个可以返回当前用户可用权限的端点，那就太棒了。

我不是安全工程师，所以我可能会遗漏一些明显的东西。所以想在投资上述实施之前征求你们的意见。

Answer 1

“授权”一词用于两种不同的上下文。

在一种情况下，授权意味着“谁拥有什么权限”。此授权的解决方案是“身份管理”。

在另一种情况下，授权意味着“谁授予谁什么权限”。此授权的解决方案是“OAuth”。

在某些情况下，您可能必须同时处理这两个授权。详情请见this question 和this answer。

Answer 2

您使用 identityserver4 标记了您的问题。

This Issue 来自去年的 identityserver3，您可能会感兴趣。 但恐怕大多数提供商不支持这个 oauth2 配置文件（还）。
UMA 似乎是一种启用细粒度授权的 oauth2 方式，但可能不是最佳解决方案。