Web services 两条腿的OAuth-寻找信息

我想基于我们的基础设施实现一个新的REST，这似乎是一条可行之路

对于我们的实现，首先只有服务器到服务器的访问，这将是完全不受限制的。我相信这就是所谓的双腿授权

稍后，我们希望允许浏览器使用API，这将使我们的授权变成三条腿的

是否有一个很好的实施起点？我们如何对服务器进行完全授权，并为每个用户添加受限授权

OAuth规范在这些场景中并没有真正的帮助，但我相信这意味着我们需要为服务器到服务器的访问创建一个永不过期的会话，然后为仅用户的API添加具有有限访问权限的正常会话

我希望找到更多信息的起点，让我知道

---

OAuth是给我的吗？我只是在寻找一个经过身份验证的请求系统，在这个场景中只有使用者和服务提供者存在。最终用户不是来玩的

记住区分身份验证和授权。在某些地方，我相信OP将两者结合在一起

例如，一旦服务器对某人进行身份验证，它通常会显式或隐式（使用cookie）提供身份验证令牌，以便后续请求已经得到授权

凭据的持续时间取决于服务器。明智的做法是计划凭据将在某个时候超时。只要让客户机服务器准备好在收到“授权过期”错误响应时重新验证自己

您不想尝试提供“永不过期”会话，因为：

一切都会在某个时刻失效。例如，如果应用程序断电或重新启动，客户端服务器将如何重新开始访问该应用程序

你正在创建一个僵化的系统。他们往往更经常地分手

因为您知道您希望在将来添加其他类型的登录，而不是两种类型的登录（服务器客户端和浏览器客户端），所以现在只进行一种类型的登录。客户端服务器的额外工作将是实现“必要时重新登录”功能

---

是的，OAuth可能是给你的

实际上有两种OAuth规范，三腿版本和两腿版本。三条腿的版本是最受关注的版本，而不是你想要使用的版本

好消息是，双腿版本正是您想要的，它允许应用程序通过共享密钥（非常类似于Amazon的Web服务模型，您将使用HMAC-SHA1签名方法）或通过公钥/私钥系统（使用签名方法：RSA-SHA1）向另一个应用程序授予访问权限。坏消息是，它还没有三条腿的版本那么受支持，所以你可能需要做更多的工作

基本上，两条腿的OAuth只指定了一种对几个字段进行“签名”（计算散列）的方法，这些字段包括当前日期、一个称为“nonce”的随机数以及请求的参数。这使得模拟对web服务的请求变得非常困难

OAuth正在慢慢地但肯定地成为这类事情的公认标准——从长远来看，如果您接受它，您将受益匪浅，因为人们可以利用各种可用的库来实现这一点

这比你一开始想了解的要复杂得多，但好消息是很多人花了很多时间在这上面，所以你知道你没有忘记任何事情。一个很好的例子是，Twitter最近发现了OAuth安全性中的一个漏洞，社区目前正在努力弥补这个漏洞。如果你发明了自己的系统，你就必须自己解决所有这些问题

---

祝你好运

OAuth对于我们的需求来说太难了。我决定采用AmazonS3的身份验证方案，只是因为它更适合我们的模型

---

谢谢你帮我找到答案

嗨，Larry，永不过期的会话是常见的做法，并不意味着我们在服务器重新启动时会丢失会话。会话存储在多个数据库和memcached实例中。对于会话，我指的是“持久令牌”。Facebook使用了这个例子。最后，我们当前的系统使用了一个“API密钥”，这是不安全的，因为它需要通过有线发送（基于几个变量的HMAC-MD5更好），并且API密钥在任何情况下都不应该最终出现在最终用户的机器上。这就是我去oauth的原因回答得很好Chris。我想没有人有过DotNetOpenAuth中的两条腿提供商的经验，是吗？