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

Question

我正在开发一种服务,提供支持的不同服务的智能(希望)集成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服务具有可返回当前用户可用权限的端点,那将是非常棒的.

我不是安全工程师,所以我可能会遗漏一些明显的东西.因此,在投资上述实施之前,想先问你们的建议.

Answer 1

"授权"一词用于两种不同的背景.

在一个上下文中,授权意味着"谁拥有什么权限".此授权的解决方案是"身份管理".

在另一方面,授权意味着"谁授予谁谁的权限".此授权的解决方案是"OAuth".

在某些情况下,您可能必须同时处理这两个授权.有关详细信息,请参阅此问题和此答案.