我正在开发一项服务，提供支持OAuth 2.0的不同服务的智能（希望）集成。我们工具的重点是团队工作流程的改进，因此我们将Slack，GitHub，Asana（问题跟踪器），Cezanne（hr工具）等组合在一起
我们有ui和后端可以使用所有这些工具（用户被授权给所有这些工具，所以我需要访问和刷新令牌）。我们需要能够隐藏ui的不同部分，具体取决于人在特定工具中的角色。我们以GitHub为例。用户可以是存储库所有者，贡献者，公司所有者（用于企业帐户）等，因此这些用户可能需要基于其权限的不同UI。
最初我对自己实施授权犹豫不决（另一个自定义授权系统是这个世界需要的最后一件事），我想利用其他服务的授权机制，只是围绕它们创建一个轻量级的包装器。起初这似乎是一个合理的想法，但我无法弄清楚如何实现它，谷歌没有给出有价值的建议，这意味着：99.99％我正在尝试做一些愚蠢的事情，00.01％我正在尝试做一些罕见的/创新的。
我希望利用OAuth 2.0，但它似乎不支持我们需要的东西。最接近的是范围，但它与我们的场景看起来并不相关。
我现在唯一的想法是创建我们自己的授权系统，并使用逆向工程集成其他服务。因此，我会使用API请求用户的GitHub帐户详细信息，并在我们的系统中适当地应用他的角色：存储库A的所有者，存储库B的贡献者，公司C的所有者等。我将必须对每个角色的权限进行反向工程（即存储库所有者无法更改公司名称）。我们必须为每项服务保留用户角色：因此，而不是典型的管理员/用户/经理/等。我们将得到：OwnerOfGitHubRepository（对于repositoryA），ManagerOfAsanaTeam（对于团队B）等。
如果OAuth 2.0服务的端点会返回当前用户可用的权限，那将是非常棒的。
我不是安全工程师，所以我可能会遗漏一些明显的东西。因此，在投资上述实施之前，想先征求大家的意见。
答案 0 :(得分：6)
“授权”一词用于两种不同的语境。
在一个上下文中，授权意味着 “谁拥有什么权限” 。此授权的解决方案是 “身份管理” 。
在其他情况下，授权是指 “授予谁” 的权限。此授权的解决方案是 “OAuth” 。
在某些情况下，您可能必须同时处理这两个授权。有关详细信息，请参阅this question和this answer。
答案 1 :(得分：2)
您使用identityserver4标记了您的问题。
对于来自去年的identityserver3，This Issue可能会让您感兴趣。
但我担心大多数提供商都不支持这个oauth2配置文件。
UMA似乎是实现细粒度授权的一种方法，但可能不是最佳解决方案。