在2013年达成了多项认证标准

 

如果我要实现一个新的服务器到服务器API，那么可以使用哪种认证标准使其他人能够轻松使用？

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

虽然有一些限制：

  • 我无法保证该API可用于HTTPS，因为它可能位于托管多个网站（具有1个IP地址）的盒子上。
  • 它应该阻止重播攻击...所以如果请求被网络上的另一个节点捕获，那么同样的请求就不能重新发送到API。
  • 理想情况下，您应该发送请求并获取响应...因此，不需要先联系API以获取一次性密钥（随机数）
  • 该请求可能应该由发件人完整签署，以避免中间人攻击。

    • 我怀疑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 2.0中的双腿oauth如何工作？

    首先需要你调用“/ 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

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

    假设我们必须对最小公分母进行编码，并使用您的需求列表（全部4项）作为我的设计种子，我会说以下内容：

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

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

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

    链接地址: http://www.djcxy.com/p/47999.html

    上一篇: legged auth standards in 2013

    下一篇: Can I Use Google OAuth 2.0 account with 1.0 hybrid protocol