27

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

要求是：

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

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

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

4

4 回答 4

20

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

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

于 2009-06-06T07:06:32.293 回答
8

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

（您可以使用任何测试客户端来帮助您完成该手动部分，或者在您自己实现服务器时：使用所谓的两足 OAuth。）

于 2009-04-22T11:12:15.590 回答
2

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

于 2009-05-03T16:39:11.783 回答
2

格雷格：

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

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

可以在此处找到我们关于扩展的 beta 文档。

于 2009-05-08T11:49:14.413 回答