OAuth2和基於角色的訪問控制

Question

我有一個充當OAuth 2.0提供程序的Rails應用程序（使用oauth2-provider gem）。 它存儲與用戶有關的所有信息（帳戶，個人信息和角色）。 有2個客戶端應用程序均通過此應用程序進行身份驗證。 客戶端應用程序可以使用client_credentials授予類型通過電子郵件查找用戶，並執行不需要授權碼的其他操作。 用戶還可以使用密碼授予類型登錄到客戶端應用程序。

現在，我們面臨的問題是用戶的角色是在資源主機上全局定義的。 因此，如果在資源主機上為用戶分配了admin角色，則該用戶在兩個客戶端上均是admin 。 我的問題是：我們應該怎么做才能擁有更細粒度的訪問控制？ 即用戶可以是app1的editor ，而不能是app2的editor者。

我想這樣做的簡單方法是更改​​角色名稱，例如： app1-admin ， app2-admin ， app1-editor ， app2-editor等。更大的問題是：我們是否正確地實現了整個系統？ 也就是說，我們應該在資源主機上存儲大量信息，還是應該將數據規范化到客戶端應用程序上？

非規范化的架構看起來像這樣：資源主機上的所有用戶數據，每個客戶端主機上的本地化用戶數據。 因此， user@example.com將其個人信息存儲在資源主機上，並將其editor角色存儲在客戶端app1 。 如果他從不使用它， app2可能會完全忘記他的存在。

非規范化模型的缺點是數據（帳戶ID，角色）和代碼（每個客戶端上的User和Role模型，單獨的管理界面等）將有大量重復。

將數據分開存在任何缺點嗎？ 客戶端應用程序都受到高度信任-我們都做到了-但是將來我們可能會添加不受我們控制的其他客戶端應用程序。

Answer 1

我認為，使用oAuth和其他類似的外部授權方法的最正確方法是嚴格的身份驗證。 所有業務/授權邏輯都應始終在服務器上處理，並且您應始終保持用戶的中央記錄，並鏈接到每種外部身份驗證服務類型的外部信息。

如果要使您的設置具有可伸縮性和面向未來，則必須具有多級/多部分訪問權限。 這是一種標准設計，與任何授權邏輯分開，並且始終與業務規則直接相關。

Stackoverflow會執行類似的操作，要求您使用外部方法登錄后在站點上創建一個實際帳戶。

更新：如果站點真的很相似，您可以將此設計子集化為每個應用程序的對象，以保留應用程序特定的訪問規則。 該對象還必須從具有全局規則的全局對象繼承（因此，例如，您可以在應用程序范圍或企業范圍內強行禁止）。

我將選擇包含訪問權限設置的對象，以及僅與自動/緊湊訪問分配有關的角色，這些角色可以與應用程序級別設置和全局設置的實例相關聯。

實際上，即使它們不太相似，您也可以使用此設計。 這將幫助您避免冗余設置和無意義的（業務方面）角色。 您可以僅通過職務/目的來識別角色，然后通過鏈接到適當的訪問設置來施加限制。