2013年的双腿认证标准 - 我们应该使用oAuth2吗？

Question

如果我要实现一个新的服务器到服务器API,有哪些身份验证标准可以让其他人轻松使用？

理想情况下,我需要记录的关于身份验证如何工作的越少越好(因此标准),并且使用该服务的开发人员更有可能使用标准库.

但有些限制:

• 我不能保证API可以在HTTPS上使用,因为它可能位于托管多个网站(具有1个IP地址)的盒子上.
• 它应该阻止重放攻击......因此,如果请求被网络上的另一个节点捕获,则无法将相同的请求重新发送到API.
• 理想情况下,您应该发送请求并获取响应...因此无需首先联系API以获取一次性密钥(nonce)
• 该请求可能应由发件人完整签名,以避免中间人类攻击.

我怀疑SSL类型设置有点太复杂,因为似乎大多数开发人员并不真正知道如何正确实现它.

使用oAuth 1.0,它看起来很简单:

http://provider.example.net/profile
    Authorization: OAuth realm="http://provider.example.net/",
    oauth_consumer_key="dpf43f3p2l4k3l03",
    oauth_signature_method="HMAC-SHA1",
    oauth_signature="IxyYZfG2BaKh8JyEGuHCOin%2F4bA%3D",
    oauth_timestamp="1191242096",
    oauth_token="",
    oauth_nonce="kllo9940pd9333jh",
    oauth_version="1.0"

但开发人员现在似乎正专注于oAuth 2,其中一个可能的解决方案是:

两条腿的oauth如何在OAuth 2.0中运行？

首先要求你调用"/ oauth/token"来获取一个令牌,但似乎没有太多关于这实际如何工作的规范形式(参见回复):

http://www.ietf.org/mail-archive/web/oauth/current/msg07957.html

然而,有一些提及在oAuth 2中使用MAC,这可能是有用的...例如,授权一次获取MAC(没有登录详细信息),保持半无限期,并重新使用所有后续要求:

http://blog.facilelogin.com/2013/01/oauth-20-bearer-token-profile-vs-mac.html

还有一个关于HMAC的有趣讨论,这意味着它没有关于如何工作的标准:

http://flascelles.wordpress.com/2010/01/04/standardize-hmac-oauth-restful-authentication-schemes/

---

其他说明:

oAuth 1.0的实施,文档和讨论:

http://www.ietf.org/mail-archive/web/oauth/current/msg06218.html https://developers.google.com/accounts/docs/OAuth#GoogleAppsOAuth http://oauth.googlecode.com/ SVN /规格/ EXT/consumer_request/1.0 /草稿/ 2/spec.html

不幸的是,我读到的oAuth 2.0越多,我就越认同Eran Hammer:

现在提供的是授权协议的蓝图,"这是企业的方式",提供"销售咨询服务和集成解决方案的全新前沿". http://en.wikipedia.org/wiki/OAuth

Answer 1

克雷格,很好的问题.我不是专家,但是对此有很多想法,所以有些想法.

假设我们必须针对最低公分母进行编码,并使用您的需求列表(所有4个项目)作为我的设计种子,我会说以下内容:

1. 无SSL - 由于您无法保证SSL,因此您必须使用公钥/私钥HMAC设计.让我们假设所有流量都是通过HTTP进行无限嗅探,这意味着您无法通过线路将任何安全令牌或签名密钥传输给呼叫者,这意味着他们已经需要它们,这意味着私有签名密钥a-la像AWS那样的东西(或两条腿的OAuth或我在上面那篇文章中概述的内容).
2. 无重播 - 使用随机数阻止重放不需要由服务器生成,您可以在此处使用任何值.nonce只需要是唯一的,需要包含在你的HMAC计算(签名)中,服务器需要记住它.例如,在客户端上生成UUID作为nonce,签署请求,将其发送到服务器:?sig=<a mess of chars>&args=<more stuff>&nonce=f81d4fae-7dec-11d0-a765-00a0c91e6bf6- 服务器将记录f81d4fae-7dec-11d0-a765-00a0c91e6bf6为已处理,并且永远不允许再次使用它.您可以在合理的时间(月份？取决于速度/使用/等)后安全地从DB中过期.提示:这是使用Redis SETs和SISMEMBER命令的完美用例.
3. (见#2,综合答案)
4. 请求必须由发件人完整签名.理解"需要签名的内容"的关键很简单:在HMAC(签名)计算中不包含的任何内容都可以由中间人(MITM)操纵.包含在信号中的所有内容都是安全的,如果没有签名检查失败,则无法更改.这就是为什么OAuth规范(两者都)都有关于字节顺序参数的迂腐规则,以及如何附加它们以及如何组合它们,但是你签署了整个请求.有些API说的很简单,比如"获取整个查询字符串并对其进行签名" - 但有时您会在该签名中获得太多内容,例如您可能不想要的域名或端点,并且需要在未来(或许你做,你是电话).

您知道,当您不需要HTTPS进行所有通信的那一刻,使安全API设计立即变得痛苦的事情就是这样.一旦你这样做,你必须转向HMAC的/签名请求和nonce的解决方案.如果您与服务器的通信是通过HTTPS保护的,并且两者可以相互信任,那么生活会变得更好,您可以执行简单的基本身份验证等操作,并且只需向服务器提供API_KEY即可确定每个请求以确定谁(或什么)正在进行请求.

希望有所帮助!看来你已经对此进行了相当多的研究,所以如果你已经知道这一切并且没有帮助,我很抱歉.