使用 OAuth 进行服务器到服务器身份验证？答案

【问题标题】：Using OAuth for server-to-server authentication?使用 OAuth 进行服务器到服务器身份验证？
【发布时间】：2010-10-21 01:44:31
【问题描述】：

我目前正在努力指定我公司的新合作伙伴/公共 API，这将是一个面向资源的 RESTful Web 服务。目前缺少的难题是身份验证/授权。

要求是：

最初它必须适用于服务器到服务器的环境，例如服务器应用程序必须能够识别自己，以便我们知道谁在调用 API。
将来，我们希望允许它模拟用户帐户，以便在识别服务器的同时，它会有一个在有限时间内代表用户帐户的令牌。

OAuth 似乎非常适合 (2) 的工作流程，即获取令牌、重定向到用户输入其凭据以对其进行授权的网站，然后使用该令牌来识别/验证应用程序和用户。

但是，根据我的阅读，我不知道它是否适合 (1) - 即有没有什么方法可以使用 OAuth 只是来识别调用应用程序而无需一个有效的用户特定令牌，因此不需要重定向到网页让他们输入他们的凭据？

【问题讨论】：

标签： authentication authorization oauth

【解决方案1】：

实际上有两种 OAuth 规范，3-legged 版本和 2-legged 版本。三足版本是最受关注的版本。

2-legged 版本完全符合您最初的要求，它允许应用程序通过共享密钥授予对另一个应用程序的访问权限（非常类似于 Amazon 的 Web 服务模型，您将使用 HMAC-SHA1 签名方法）或通过公钥/私钥系统（使用签名方法：RSA-SHA1）。坏消息是，它还没有像 3-legged 版本那样得到很好的支持，所以你现在可能需要做更多的工作。

基本上，2-legged OAuth 只是指定一种“签名”（计算哈希）几个字段的方法，这些字段包括当前日期、一个称为“nonce”的随机数以及您的请求参数。这使得模拟对您的 Web 服务的请求非常困难。

OAuth 正在缓慢但肯定会成为此类事情的公认标准 - 从长远来看，如果你接受它，你会得到最好的结果，因为人们可以利用各种可用的库来做到这一点。

让 2 条腿和 3 条腿同时工作现在有点棘手 - 但它是可能的（谷歌现在可以工作）。 http://code.google.com/apis/accounts/docs/OAuth.html

【讨论】：

【解决方案2】：

格雷格：

我一直在研究 OAuth 核心的扩展，我认为它可能会满足您的需求。我们想针对我们自己的 API 编写应用程序，但我们认为不允许我们自己的应用程序（作为服务提供者）直接从用户/消费者应用程序收集凭据没有多大意义——因为我们已经被认为是受信任的参加我们自己的聚会。

该扩展允许第一方、第二方，当然还有第三方（传统的 OAuth），同时使用协议提供的令牌和机密以及签名等安全性。

可以在here 找到我们关于扩展的测试版文档。

【讨论】：

【解决方案3】：

如果只是关于服务器到服务器的通信，我会考虑使用基于 API 密钥的授权 - 就像 bit.ly 或 FriendFeed。

【讨论】：

能写更多关于它的内容吗？ OAuth 基于 API 密钥（名称不同）。

【解决方案4】：

是的，令牌的生命周期可以设置为不过期，直到你说出来。因此，您将（手动）完成身份验证和授权，并保存授权令牌以供以后使用。

（您可以使用any test client 来帮助您完成该手动部分，或者在您自己实现服务器时：使用所谓的双腿 OAuth。）

【讨论】：

2-legged OAuth 看起来很有希望...如果结果证明是我需要的，我会研究一下并将其标记为正确答案。
请注意，OAuth 还确保请求不会被篡改（在不使用 HTTPS 时也是如此）。
@Arjan 你能描述一下 OAuth 在不使用 HTTPS 时如何确保请求不会被篡改吗？
@sank，我假设我的意思是“OAuth 请求”（而不是使用 OAuth 令牌的后续其他请求）。但即便如此，我也不知道我为什么要写那个...... :-(