使用OAuth进行服务器到服务器身份验证？
我目前正在努力指定我公司的新合作伙伴/公共应用程序接口，它将是一个面向资源的RESTful web服务。目前缺少的一块是身份验证/授权。
要求是：
- 最初它必须适用于服务器到服务器的环境，例如，服务器应用程序必须能够标识自身，以便我们知道谁在调用。将来，我们希望允许它模拟用户帐户，以便被标识的服务器在有限的一段时间内具有代表用户帐户的令牌。
OAuth似乎非常适合(2)获取令牌的工作流程，重定向到用户输入凭据进行授权的网站，然后使用标识/验证应用程序和用户的令牌。
然而，从我所读到的内容来看，我不知道它是否适合(1) --也就是说，有没有办法让OAuth只用来识别调用应用程序，而不需要拥有有效的用户特定令牌，从而不需要被重定向到网页来输入他们的凭据？
回答 4
Stack Overflow用户
发布于 2009-04-22 11:12:16
是的，可以将令牌的生命周期设置为在您指定之前不会过期。因此，您需要(手动)完成身份验证和授权，并保存授权的令牌以供以后使用。
(您可以使用any test client来帮助您完成手动部分，或者在您自己实现服务器时:使用所谓的两条腿的OAuth。)
Stack Overflow用户
发布于 2009-06-06 07:06:32
实际上有两个OAuth规范，三条腿的版本和两条腿的版本。三条腿的版本是最受关注的版本。
两条腿的版本做的正是您最初想要的，它允许应用程序通过共享密钥(非常类似于Amazon的Web服务模型，您将使用HMAC-SHA1签名方法)或通过公钥/私钥系统(使用签名方法: RSA-SHA1)授予对另一个应用程序的访问权限。坏消息是，它还没有像三条腿的版本那样得到很好的支持，所以你现在可能需要做比其他方式更多的工作。
基本上，两条腿的OAuth只是指定了一种方法来“签名”(计算哈希)几个字段，其中包括当前日期，一个称为“随机数”的随机数，以及请求的参数。这使得很难模拟对您的web服务的请求。
OAuth正在慢慢但肯定地成为这类事情的公认标准--如果您接受它，从长远来看，您将是最好的，因为人们可以利用各种可用的库来做这件事。
现在让两条腿和三条腿同时工作有点棘手--但这是可能的(谷歌现在已经让它工作了)。http://code.google.com/apis/accounts/docs/OAuth.html
Stack Overflow用户
发布于 2009-05-03 16:39:12
如果只是服务器到服务器的通信，我会考虑使用基于API的授权-就像bit.ly或FriendFeed一样。
https://stackoverflow.com/questions/776679
复制相似问题