2017-10-11 59 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方式來實現細粒度的授權,但可能不是最好的解決方案。