我目前正在努力指定我公司的新合作伙伴 / 公共 API,这将是一个面向资源的 RESTful Web 服务。目前缺少的一块难题是身份验证 / 授权。
要求如下:
最初，它必须适用于服务器到服务器的环境，例如，服务器应用程序必须能够识别自己，以便我们知道谁在调用 API。
在未来，我们希望允许它模拟用户帐户，以及被识别的服务器，它将有一个令牌，代表一个有限的时间内的用户帐户。
OAuth 似乎是理想的（2）与获得令牌的工作流，重定向到用户输入他们的凭据授权它的网站，然后使用该令牌识别 / 验证应用程序和用户。
但是，从我所读到的，我不知道它是否适合（1）-即有什么方法可以使用 OAuth只是来识别调用应用程序而没有有效的用户特定令牌，因此不需要重定向到网页，让他们输入他们的凭据？
实际上有两种 OAuth 规格，即 3 条腿版本和 2 条腿版本，其中 3 条腿版本最受关注。
2-legged 版本最初完全可以执行您想要的操作，它允许应用程序通过共享密钥（非常类似于 Amazon 的 Web Service 模型，您将使用 HMAC-SHA1 签名方法）或通过公共 / 私有密钥系统（使用签名方法：RSA-SHA1）。坏消息是，它的支持程度还不如 3-legged 版本，因此您现在可能需要做更多的工作。
基本上，2-legged OAuth 只是指定一种方式来“签名”（计算哈希值）几个字段，其中包括当前日期，一个名为“nonce”的随机数以及请求的参数。这使得很难将请求模拟到您的 Web 服务。
OAuth 正在缓慢但肯定地成为这种事情的公认标准-从长远来看，如果你接受它，你会是最好的，因为人们可以利用各种库来做到这一点。
让两条腿和三条腿同时工作现在有点棘手--但这是可能的 (谷歌现在已经开始工作了)。http://code.google.com/a/accounts/docs/OAuth.html
是的，令牌的生命周期可以设置为在您这样说之前不会过期。因此，您将（手动）完成身份验证和授权，并保存授权的令牌以供以后使用。
（您可以使用any test client来帮助您完成手动部分，或者当您自己实现服务器时：使用所谓的两条腿 OAuth。）
如果它只是关于服务器到服务器的通信，我会考虑使用基于 API 密钥的授权-就像 bit.ly 或 FriendFeed。
格雷格:
我们想针对我们自己的 API 编写应用程序，但我们觉得不允许我们自己的应用程序（作为服务提供商）直接从用户 / 消费者应用程序收集凭据没有多大意义-因为我们已经被认为是我们自己的受信任方。
该扩展允许第一，第二，当然还有第三方（传统的 OAuth），同时使用协议提供的令牌和秘密以及签名等的安全性。
我们关于扩展的 beta 文档可以找到here。
本站系公益性非盈利分享网址，本文来自用户投稿，不代表边看边学立场，如若转载，请注明出处
评论列表（30条）