如果我要实现一个新的服务器到服务器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，一个可能的解决方案是:
2-legged 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.htmlhttps://developers.google.com/accounts/docs/OAuth#GoogleAppsOAuthhttp://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/spec.html
不幸的是，我对oAuth 2.0读得越多，我就越同意Eran Hammer的观点:
现在提供的是授权的蓝图"协议"即企业方式，提供了"全新"Frontier出售咨询服务和集成解决方案"。http://en.wikipedia.org/wiki/OAuth
Craig，问得好。我不是专家，但我想了很多，所以几点想法。
假设我们必须根据最低公分母进行编码，并使用您的需求列表(所有4项)作为我的设计种子，我会说以下内容:
- 没有SSL -因为你不能保证SSL，你将不得不使用公钥/私钥HMAC设计。让我们假设所有流量都是通过HTTP进行的，并且是无限可嗅嗅的，这意味着您不能在任何时候通过网络向调用者传输任何安全令牌或签名密钥，这意味着他们已经需要它们了，这意味着一个私有签名密钥，就像AWS所做的那样(或2腿OAuth或我在上面的文章中概述的那样)。
-
No Replay -使用nonce来阻止重播不需要服务器生成它，您可以在这里使用任何值。nonce只需要是唯一的，需要包含在你的HMAC计算(签名)中，并且服务器需要记住它。例如，在客户端上生成一个UUID作为nonce，对请求签名，将其发送到服务器:
?sig=<a mess of chars>&args=<more stuff>&nonce=f81d4fae-7dec-11d0-a765-00a0c91e6bf6——服务器将f81d4fae-7dec-11d0-a765-00a0c91e6bf6记录为已处理，并且永远不允许再次使用它。您可能可以在合理的时间(月?取决于速度/使用情况等)。提示:对于使用Redis SETs和SISMEMBER命令来说，这是一个完美的用例。 - (见#2，综合答案)
- 请求必须由发送方完整签名。理解"什么需要被签名"的关键很简单:任何你不包括在HMAC(签名)计算中的东西都可以被中间人(MITM)操纵。包含在签名中的一切都是安全的，没有签名检查失败就不能更改。这就是为什么OAuth规范(它们两个)有关于字节排序参数、如何附加参数以及如何组合参数的迂旧规则，但是您对整个请求进行签名。有些api会说一些简单的东西，比如"取整个查询字符串，并对其签名"——但有时你在签名中得到的东西太多了，比如域名或端点，你可能不希望在那里，需要在将来更改它(或者你可能这样做，你调用)。
正如你所知道的，使安全API设计立即痛苦的事情是你不需要所有通信都使用HTTPS的那一刻。一旦你这样做，你必须转向解决方案，如HMAC/签名请求和nonce的。如果你与服务器的通信是通过HTTPS安全的，双方都可以相互信任，生活就会变得更好，你可以做一些简单的基本认证，只给服务器一个API_KEY与每个请求来识别谁(或什么)发出请求。
希望有帮助!看来你已经研究了很多了，所以如果你已经知道了所有这些，但它没有帮助，我很抱歉。