2013 年的两足认证标准——我们应该使用 oAuth2 吗？

Question

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

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

但有一些限制：

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

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

使用 oAuth 1.0，it seems fairly simple：

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 项）作为我的设计种子，我会说以下内容：

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

您知道，让安全 API 设计立即痛苦的是，您不需要 HTTPS 进行所有通信。一旦你这样做了，你就必须求助于像 HMAC's/signing requests 和 nonce's 这样的解决方案。如果您与服务器的通信是通过 HTTPS 保护的，并且两者都可以相互信任，那么生活会变得更好，您可以执行简单的基本身份验证之类的操作，并且只需在每个请求中为服务器提供一个 API_KEY 以识别是谁（或什么）在进行请求。

希望对您有所帮助！看来您已经对此进行了相当多的研究，所以如果您已经知道这一切并且没有帮助，我深表歉意。