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

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

要求是:

最初它必须适用于服务器到服务器环境,例如服务器应用程序必须能够识别自身,以便我们知道谁在调用API.

将来,我们希望允许它模拟用户帐户,因此,在识别服务器时,它将具有代表用户帐户的令牌,该令牌在有限的时间段内.

OAuth似乎是理想的(2)获取令牌的工作流程,重定向到用户输入其凭据以授权它的网站,然后使用该标记来识别/验证应用程序和用户.

但是,从我读,我不知道这是否是适合于(1) -即是否有任何方式的OAuth可以用来只是识别调用应用程序,而无需有效的用户特定的标记,因此不需要要重定向到网页,以便他们输入凭据？

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

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

基本上,两条腿OAuth只是指定了一种方式来"签名"(计算哈希)几个字段,包括当前日期,一个名为"nonce"的随机数,以及您的请求的参数.这使得很难模拟对您的Web服务的请求.

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

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

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

(您可以使用任何测试客户端来帮助您完成该手动部分,或者在您自己实施服务器时:使用所谓的双腿OAuth.)