OAuth2 和基于角色的访问控制

Question

我有一个作为 OAuth 2.0 提供者的 Rails 应用程序（使用oauth2-provider gem）。它存储与用户相关的所有信息（帐户、个人信息和角色）。有 2 个客户端应用程序都通过此应用程序进行身份验证。客户端应用程序可以使用client_credentials授权类型通过电子邮件查找用户并执行其他不需要授权代码的操作。用户还可以使用密码授权类型登录客户端应用程序。

现在我们面临的问题是用户的角色是在资源主机上全局定义的。因此，如果admin在资源主机上为用户分配了角色，则该用户admin在两个客户端上。我的问题是：我们应该怎么做才能拥有更细粒度的访问控制？即用户可以是editorforapp1但不是 for app2。

我想最简单的方式来做到这一点是改变像这样的角色名：app1-admin，app2-admin，app1-editor，app2-editor，等更大的问题是：我们是否正确执行这一整个系统; 也就是说，我们应该在资源主机上存储这么多信息，还是应该将数据非规范化到客户端应用程序上？

非规范化架构看起来像这样：资源主机上的所有用户数据，每个客户端主机上的本地化用户数据。因此user@example.com，他将在资源主机上拥有他的个人信息，并将他的editor角色存储在 client 上app1。如果他从不使用它，app2可能会完全忘记他的存在。

非规范化模型的缺点是数据（帐户 ID、角色）和代码（User以及Role每个客户端上的模型、单独的管理接口等）会有大量重复。

将数据分开有什么缺点吗？客户端应用程序都受到高度信任——我们同时制作了它们——但我们可能会在未来添加其他客户端应用程序，这些客户端应用程序不受我们的控制。

Answer 1

在我看来，使用 oAuth 和其他类似的外部授权方法的最正确方法是用于严格的身份验证目的。所有业务/授权逻辑应始终在您的服务器部分处理，并且您应始终保留用户的中央记录，链接到每个外部类型的身份验证服务的外部信息。

如果您希望您的设置具有可扩展性且面向未来，那么拥有多级/多部分访问权限也是必须的。这是一个标准设计，独立于任何授权逻辑，并且始终与业务规则直接相关。

Stackoverflow 会执行类似的操作，要求您在使用外部方法登录后在网站上创建一个实际帐户。

更新：如果站点确实相似，您可以将此设计子集为每个应用程序的一个对象，以保留应用程序特定的访问规则。该对象还必须继承自具有全局规则的全局对象（因此您可以在应用程序范围或企业范围内实施禁令）。

我会选择包含访问设置的对象，以及可以与应用程序级别设置和全局设置的实例相关的角色，仅用于自动化/压缩访问分配。

实际上，即使它们不太相似，您也可以使用这种设计。这将帮助您避免冗余设置和无意义（业务方面）的角色。您可以纯粹通过职位/目的来识别角色，然后通过链接到适当的访问设置设置来施加限制。