两条腿OAuth - 寻找信息

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

对于我们的实现,首先将是服务器到服务器访问,这将是完全不受限制的.我相信这被称为双腿授权.

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

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

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

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

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

Ya,OAuth可能适合你.

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

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

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

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

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

祝好运!

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

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

服务器取决于凭证的持续时间.计划凭证在某些时候超时是明智的.只要客户端服务器准备好在收到"授权过期"错误响应时重新进行身份验证.

您不希望尝试提供"永不过期"的会话,因为:

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

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

由于您知道将来要添加其他类型的登录,而不是两种类型的登录(服务器客户端和浏览器客户端),现在只需要一种登录类型.客户端服务器的额外工作是实现"根据需要重新登录"功能.