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

Question

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

要求是：

1. 最初它必须适用于服务器到服务器环境，例如：服务器应用程序必须能够识别自身，以便我们知道谁在调用API。
2. 将来，我们希望允许它模拟用户帐户，因此，除了被识别的服务器之外，它还会有一个代表用户帐户一段时间的令牌。

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

但是，从我读过的内容来看，我不知道它是否适用于（1） - 即是否有任何方法可以使用 来识别调用应用程序而无需一个有效的用户特定令牌，因此无需重定向到网页，以便他们输入凭据？

Answer 1

实际上有两个OAuth规范，即3脚版本和2脚版本。三脚版本是最受关注的版本。

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

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

OAuth正在缓慢但肯定地成为这种事情的公认标准 - 如果您接受它，那么从长远来看，您将是最好的，因为人们可以利用各种可用的库来实现这一目标。

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

Answer 2

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

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

Answer 3

格雷格：

我一直在努力扩展OAuth核心，我认为可能会回答您的需求。我们想要针对我们自己的API编写应用程序，但我们认为不允许我们自己的应用程序（作为服务提供者）直接从用户/消费者应用程序收集凭证没有多大意义 - 因为我们已经被认为是受信任的我们自己的一方。

扩展允许第1，第2，当然还有第3方（传统OAuth），同时使用协议提供的令牌和秘密，签名等安全性。

我们可以找到有关扩展程序的测试版文档here。

Answer 4

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