我有一个作为 OAuth 2.0 提供者的 Rails 应用程序(使用 oauth2-provider gem)。它存储与用户相关的所有信息(帐户、个人信息和角色)。有 2 个客户端应用程序都通过此应用程序进行身份验证。客户端应用程序可以使用 client_credentials授予类型通过电子邮件查找用户并执行其他不需要授权代码的操作。用户还可以使用密码授权类型登录客户端应用程序。
现在我们面临的问题是用户的角色是在资源主机上全局定义的。因此，如果给用户一个 admin资源主机上的角色，该用户是 admin在两个客户端上。我的问题是:我们应该怎么做才能拥有更细粒度的访问控制？ IE。用户可以是 editor为 app1但不适用于 app2 .
我想这样做的简单方法是像这样更改角色名称:app1-admin , app2-admin , app1-editor , app2-editor等等。更大的问题是:我们是否正确地实现了整个系统；也就是说，我们应该在资源主机上存储这么多信息，还是应该将数据非规范化到客户端应用程序上？
非规范化架构看起来像这样:资源主机上的所有用户数据，每个客户端主机上的本地化用户数据。所以user@example.com将在资源主机上拥有他的个人信息并拥有他的 editor角色存储在客户端 app1 .如果他从不使用它，app2可以完全忘记他的存在。
非规范化模型的缺点是数据(帐户 ID、角色)和代码(每个客户端上的 User 和 Role 模型、单独的管理界面等)会有大量重复。
将数据分开有什么缺点吗？客户端应用程序都受到高度信任——我们同时制作了它们——但我们将来可能会添加其他客户端应用程序，这些应用程序不受我们的控制。
最佳答案
在我看来，使用 oAuth 和其他类似外部授权方法的最正确方法是严格用于身份验证目的。所有业务/授权逻辑都应始终在您的服务器部分处理，并且您应始终保留用户的中央记录，链接到每个外部类型的身份验证服务的外部信息。
如果您希望您的设置具有可扩展性和面向 future 的能力，那么拥有多级/多部分访问权限也是必须的。这是一种标准设计，与任何授权逻辑分开，并始终与业务规则直接相关。
Stackoverflow 做了这样的事情，要求你在网站上创建一个真实的帐户 后 您使用外部方法登录。
更新:如果站点真的很相似，您可以将此设计子集到每个应用程序的对象，以保留应用程序特定的访问规则。该对象还必须从具有全局规则的全局对象继承(例如，您可以在应用程序范围或企业范围内实现禁令)。
我会去寻找包含访问设置的对象，以及可以与应用程序级别设置和全局设置的实例相关的角色，仅用于自动化/压缩访问分配。
实际上，即使它们不太相似，您也可以使用这种设计。这将帮助您避免冗余设置和无意义的(业务方面的)角色。您可以纯粹通过职位/目的来识别角色，然后通过链接到适当的访问设置设置来施加您的限制。
关于ruby-on-rails - OAuth2 和基于角色的访问控制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9604191/