2017-10-11 56 views
4

我正在致力于提供智能(希望)集成支持OAuth 2.0的不同服务的服务。我们的工具的重点是团队工作流程的改进,所以我们结合SlackGitHubAsana(问题跟踪),Cezanne(HR工具)等如何将授权委托给外部Auth 2.0服务

我们有UI和后端,与所有这些工具的工作(用户被授权所有人,所以我需要访问和刷新令牌)。我们需要能够隐藏用户界面的不同部分,这取决于用户在特定工具中的角色。以GitHub为例。用户可以是存储库所有者,贡献者,公司所有者(用于商业账户)等,因此这些用户可能需要根据他们的权利需要不同的用户界面。

本来我一直在犹豫是否自己实施授权(另一个定制授权系统是这个世界最不需要的),我想利用其他服务的授权机制,只是围绕它们创建一个轻量级包装。这似乎是一个合理的想法,但我无法弄清楚如何实现它,谷歌不会提供有价值的建议,这意味着:99.99%我试图做一些愚蠢的事情,00.01%我试图做一些罕见/创新。

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

我现在唯一的想法是创建我们自己的授权系统,并使用逆向工程来集成其他服务。因此,我会使用API​​请求用户的GitHub帐户详细信息,并在我们的系统中适当地应用他的角色:存储库A的所有者,存储库B的参与者,公司C的所有者等。我必须对每个角色的权限进行反向设计资料库所有者不能更改公司名称)。我们必须为每个服务保留用户角色:所以不要使用典型的Admin/User/Manager /等。我们将得到:OwnerOfGitHubRepository(用于repositoryA),ManagerOfAsanaTeam(用于B队)等。

如果OAuth 2.0服务有一个端点将返回可用于当前用户的权限,那将会很棒。

我不是安全工程师,所以我可能会错过一些明显的东西。所以在投资上面提到的实现之前,想要问你们的建议。

回答

6

单词“授权”用于两种不同的情况。

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

在另一方面,授权意味着“谁授予什么权限谁”。此授权解决方案为“OAuth”

在某些情况下,您可能需要同时处理这两个授权。有关详细信息,请参阅this questionthis answer

+0

感谢您证明OAuth 2.0不是解决概述问题的解决方案。很想听听你对这个问题所提出的解决方案的看法(我改变了一点,以便更清楚)。 – SiberianGuy

2

你用identityserver4标记了你的问题。

This Issue for identityserver3 from last year may may you。 但我恐怕大多数提供商不支持这个oauth2配置文件(还)。
UMA似乎是一种oauth2方式来实现细粒度的授权,但可能不是最好的解决方案。