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

Question

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

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

但是有一些限制:

我不能保证 API 将在 HTTPS 上可用，因为它可能位于托管多个网站(具有 1 个 IP 地址)的盒子上。

它应该阻止重放攻击......因此，如果请求被网络上的另一个节点捕获，则无法将相同的请求重新发送到 API。

理想情况下，您应该只发送请求并返回响应...因此无需先联系 API 以获取一次性 key (随机数)

请求可能应该由发送者完整签名，以避免中间人类型的攻击。

我怀疑 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”来获取 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。 :

What is now offered is a blueprint for an authorisation protocol, "that is the enterprise way", providing a "whole new frontier to sell consulting services and integration solutions". http://en.wikipedia.org/wiki/OAuth

Answer 1

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

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

无 SSL - 由于您不能保证 SSL，您将不得不使用公钥/私钥 HMAC 设计。让我们假设所有流量都通过 HTTP 并且可以无限嗅探，这意味着您无法在任何时候通过线路将任何安全 token 或签名 key 传输给调用者，这意味着他们已经需要它们，这意味着私有(private)签名 key a-la类似于 AWS 所做的事情(或 2-legged OAuth 或我在上面那篇文章中概述的内容)。

无重播 - 使用 nonce 来阻止重播不需要由服务器生成，您可以在此处使用任何值。随机数只需要唯一，需要包含在您的 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 的完美用例。 .

(见#2，综合答案)

请求 必须由发件人完整签名。理解“需要签名的内容”的关键很简单:在 HMAC(签名)计算中未包含的任何内容都可以由中间人 (MITM) 操作。 sig 中包含的所有内容都是安全的，如果 sig 检查失败，则无法更改。这就是为什么 OAuth 规范(两者)对字节顺序参数以及如何附加它们以及如何组合它们有迂腐的规则，但你签署了整个请求。一些 API 说的很简单，比如“获取整个查询字符串，并对其进行签名”——但有时您会在该签名中获得太多信息，例如您可能不想要的域名或端点，需要在 future (或者你可能会，你打电话)。

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

希望有帮助!看来您已经对此进行了很多研究，所以如果您已经知道所有这些并且没有帮助，我深表歉意。