用于多方认证/授权的OAuth

Question

我为一家正在进行大规模重写的网络公司工作，以便将我们的数据分离到它自己的RESTful服务应用程序中--目标是能够出售对第三方的访问权，并且能够快速建立内部应用程序原型，而不需要直接访问DB。

我们目前有三个应用程序--前面提到的数据API、CMS和前端。用户需要能够登录到CMS，通过API修改数据，我们真的很想通过Google将我们的Google集成到这个登录中。理想情况下，这将使用OAuth流，因为它对我们的用户来说是最透明的-但我不知道在应用程序之间共享OAuth信息的任何方式，而不可能损害他们的安全性。

我试过什么

具体而言？没什么。我最初的建议是生成本质上是“嵌套OAuth”的内容--将我的数据应用程序设置为所有其他应用程序的OAuth提供程序，然后在数据层中使用谷歌OAuth流作为未指定的身份验证标准--它是一个完全Restful的API，因此它对用户来说非常透明，但它似乎违反了OAuth的概念，我觉得应该有更好的方法来做到这一点。流程将如下所示：

1. 用户请求登录CMS
2. CMS从数据层获得一个Auth令牌。
3. CMS将用户重定向到数据层承载的登录页。
4. 数据层从Google获得一个Auth令牌
5. 数据层将用户重定向到Google页面
6. Google验证用户身份，然后使用Auth令牌将用户重定向回数据层。
7. 数据层使用Auth令牌为获取访问令牌
8. 数据层使用另一个Auth令牌将用户重定向回CMS。
9. Auth层使用Auth令牌为数据服务获取访问令牌

但它似乎，嗯，笨重的。我也不想强迫用户通过多个“允许”页面--一个来自Google的页面允许数据层，另一个来自数据层，以允许CMS (或稍后的应用程序)访问。我真正需要的是在SSO或Kerberos情况下使用Google，并让Google为我的应用程序提供门票。如果有人知道如何利用谷歌这一优势，我很乐意对整个设计加以抨击。

Answer 1

经过大量的研究，我发现Google有一个不安全的访问令牌验证器-- https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken，可以用来验证

1. 发出令牌的应用程序是什么？
2. 代发的电子邮件地址。

通过跟踪应用程序的Google标识符，数据层可以接受访问令牌并对其进行验证以验证用户和应用程序，只需从标准API签名方案中得到一点帮助，该方案只涉及数据层和访问应用程序所知道的秘密。这不需要信任，因为每个需要数据层信息的应用程序都可以向Google oAuth注册自己，如果没有它们之间共享的秘密，Data就不能代表用户使用访问令牌。这确实阻止了数据层代表用户访问Google，但是可以为Data实现一个单独的oAuth来访问用户的资源。

Answer 2

我认为你提出的解决方案是你要找到的最好的办法。

让我们重温一下你的问题，看看我是否正确理解。您有一个“数据层”，它存储用户拥有的数据。用户通过Google的OAuth端点进行身份验证。您也有许多“前端”应用程序可以访问数据层，但不被隐式信任。您想要的行为是，如果用户A批准“前端应用程序A”，则该应用程序可以访问数据层中属于用户A的数据，但不能访问属于其他用户的数据。

为了支持这个设计，每个用户都必须显式地批准他们使用的每一个前端应用程序--尽管他们只需要这样做一次。这是设计中固有的。问题是用户是直接使用Google认证前端应用程序，还是使用数据层中的OAuth提供程序进行身份验证。

如果他们直接使用Google，那么前端应用程序就会知道用户的身份。然而，前端应用程序无法向数据层安全地证明它知道用户的身份。OAuth不支持这一点，这是一个很好的理由。在这个设置中，用户在什么时候同意允许“前端应用程序A”访问数据层？您的数据层没有能力向Google的OAuth端点添加功能。

使用您建议的“嵌套OAuth”设置，用户确实会看到这样的消息。当他们批准时，前端应用程序可以安全地向数据层证明用户已经批准了应用程序。

在前端和数据层之间，您使用的是最初打算使用的OAuth --向网站上的数据授予一些外部应用程序特权。在数据层和谷歌之间，您正在使用OAuth进行身份验证，这是一个稍微不同的用例。

顺便提一下，您提到了Kerberos，但这也有相同的问题。在Kerberos环境中，您可以向邮件服务器和文件服务器标识自己，但邮件服务器不能代表您对文件服务器进行身份验证。