两条腿OAuth - 寻找信息

Question

我想在我们的基础架构上实现一个基于REST的新API，OAuth似乎是要走的路。

对于我们的实施，首先是服务器到服务器的访问，这将是完全不受限制的。我相信这被称为两条腿授权。

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

实施这个有一个很好的起点吗？我们如何完全授权服务器并在未来为每个用户添加受限授权？

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

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

OAuth对我来说？我只是在寻找经过身份验证的请求系统，在这种情况下只存在消费者和服务提供者。最终用户不参与游戏！

Answer 1

雅，OAuth可能适合你。

实际上有两个OAuth规范，即3脚版本和2脚版本。 3脚版本是最受关注的版本，并且不是您想要使用的版本。

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

基本上，两条腿OAuth只是指定了一种方式来“签名”（计算哈希）几个字段，包括当前日期，一个名为“nonce”的随机数，以及请求的参数。这使得非常难以模拟对您的Web服务的请求。

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

它比你最初想要进入的更精细 - 但好消息是很多人花了很多时间在你身上，所以你知道你没有忘记任何事情。一个很好的例子是，最近Twitter发现社区目前正在努力关闭的OAuth安全性存在差距。如果你发明了自己的系统，那么你必须自己弄清楚所有这些。

祝你好运！

Answer 2

请记住区分身份验证和授权。在某些地方，我认为OP混合了两者。

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

服务器取决于凭证的持续时间。 计划明智的是，凭据会在某个时刻超时。只要客户端服务器准备好在收到“授权过期”错误响应时重新进行身份验证。

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

1. 一切都会在某个时刻到期。例如，如果客户端服务器断电或重新启动，它将如何能够再次开始访问应用程序？

2. 您正在创建一个不灵活的系统。他们往往会更频繁地休息。

3. 由于您知道以后要添加其他类型的登录，而不是两种类型的登录（服务器客户端和浏览器客户端），现在只需登录一种类型。客户端服务器的额外工作是实现“根据需要重新登录”功能。

Answer 3

OAuth最终将难以满足我们的需求。我决定采用Amazon S3的身份验证方案，因为它更适合我们的模型。

感谢您帮助寻找答案..