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

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

(可以使用) any test client 为了帮助您完成手册中的部分,或者在您自己实现服务器时:使用所谓的两腿OAuth。)

实际上有两个OAuth规范,三条腿版本和两条腿版本。三条腿的版本是最受关注的版本。

两条腿的版本完全满足您最初的需求,它允许应用程序通过共享密钥(非常类似于Amazon的Web服务模型,您将使用hmac-sha1签名方法)或通过公钥/私钥系统(使用签名方法:rsa-sha1)向另一个应用程序授予访问权限。坏消息是,它的支持还不如3条腿版本,所以你可能需要做更多的工作,而不是你现在可能需要做的。

基本上,两条腿的OAuth只指定了一种方法来“签名”(计算哈希)几个字段,其中包括当前日期、称为“nonce”的随机数以及请求的参数。这使得它 很辛苦 模拟对Web服务的请求。

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

现在让2条腿和3条腿同时工作有点棘手——但这是可能的(谷歌现在已经让它工作了)。 http://code.google.com/apis/accounts/docs/OAuth.html

格雷戈:

我一直在研究OAuth核心的扩展,我认为可以满足您的需要。我们想用我们自己的API编写应用程序,但我们觉得不允许我们自己的应用程序(作为服务提供商)直接从用户/消费者应用程序收集凭据没有多大意义,因为我们已经被视为自己的受信任方。

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

我们的扩展测试文档可以找到 here .

如果只是关于服务器到服务器的通信,我会考虑使用基于API密钥的授权——就像bit.ly或friendfeed一样。