Question

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

理想情况下，我需要记录的有关身份验证的工作方式越少越好（因此标准），并且使用该服务的开发人员更有可能使用标准库。

但有些限制：

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

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

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，其中一个可能的解决方案是：

How does 2-legged oauth work in 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/spec/ext/consumer_request/1.0/drafts/2/spec.html

不幸的是，我对oAuth 2.0的了解越多，我就越同意Eran Hammer：

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

Answer 1

克雷格，很好的问题。我不是专家，但有thought a lot about this，所以有一些想法。

假设我们必须针对最低共同点进行编码，并使用您的需求列表（所有4个项目）作为我的设计种子，我会说以下内容：

无SSL - 由于您无法保证SSL，因此您必须使用公钥/私钥HMAC设计。让我们假设所有流量都是通过HTTP进行无限嗅探，这意味着您无法通过线路将任何安全令牌或签名密钥传输给呼叫者，这意味着他们已经需要它们，这意味着私有签名密钥a-la像AWS那样的东西（或两条腿的OAuth或我在上面那篇文章中概述的内容）。
无重播 - 使用随机数阻止重播不需要由服务器生成，您可以在此处使用任何值。 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 SET和SISMEMBER command的完美用例。
（见＃2，合并答案）
请求必须由发件人完整签名。理解“需要签名的内容”的关键很简单：在HMAC（签名）计算中不包含的任何内容都可以由中间人（MITM）操纵。包含在信号中的所有内容都是安全的，如果没有签名检查失败，则无法更改。这就是为什么OAuth规范（两者都）都有关于字节排序参数的迂腐规则，以及如何附加它们以及如何组合它们，但是你签署了整个请求。有些API说的很简单，比如“获取整个查询字符串并对其进行签名” - 但有时您会在该签名中获得太多内容，例如您可能不想要的域名或端点，并且需要在未来（或者你可以，你正在打电话）。

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

希望有所帮助！看来你已经对此进行了相当多的调查，所以如果你已经知道这一切并且没有帮助，我很抱歉。

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

1 个答案: