该标准应解决以下身份验证挑战，例如-
重放攻击 中间人 明文攻击 字典攻击 蛮力攻击 假冒服务器的欺骗
我已经看过 Amazon Web Services，这是一种可能性。更重要的是，似乎有两种最常见的方法：
签名通常是通过使用加密的共享秘密签署日期戳来获得的。因此，此签名作为 apiKey 或在 Http AuthenticationHeader 中传递。
我想知道来自社区的两种选择，他们可能已经使用过一种或多种选择，并且还想探索我没有考虑的其他选择。我也会使用 HTTPS 来保护我的服务。
“认证”的意思是：向我证明你就是你所说的那个人
“你是谁”是一个实体的身份（个人、计算机用户、软件、服务器等......）
“身份”是每个实体唯一的属性（dba 会在这里说主键）
因此，您必须以某种方式证明具有该独特属性。当这里的实体是 HTTP 客户端时，HTTP Auth 是向服务器证明其唯一身份（我们称之为用户名）的标准化方式。
它不关心通道的安全性，这就是表示层（即 SSL）的用途，并且需要各部分之间共享秘密。“共享秘密”意味着双方都必须知道，其他人都不知道。这意味着两部分相互信任，不会泄露秘密或在泄露后采取适当措施（例如，更改秘密）。
HTTP 作为一种协议不包括其他方式来进行授权，并将其留在其他层。例如，SSL 可以证明双方的身份，而无需通过使用公钥基础设施（证书和证书颁发机构）共享秘密。
到底：
如果您可以在各方之间共享一个秘密，您可以使用 HTTP Auth 进行身份验证并使用 SSL 来保护通道。安全交换和存储共享秘密取决于各方
如果您不想共享秘密，但双方可以就共同的受信任第三方达成一致，您可以使用纯 HTTP 并使用 SSL 来保护通道并使用 PKI 证明一方或双方的身份（>证书）
还有很多其他的可能性，但这两个是我能想到的最标准的，应该与大多数现有的 HTTP 软件/库/任何东西兼容
自制系统虽然在技术上是有效的，但要么打破公认的标准，要么是在应用层实施的临时（因此非标准）系统（以解决应该在另一层解决的问题，呸）
如果不同意共享秘密（并将其保密）或同意信任其他人来处理该独特性（PKI），就无法证明某事物的独特性。其他一切都只是实现细节。
我不确定是否有一个标准。如果有，它可能是 HTTP Auth，（基本或摘要）。上述两个都是相当糟糕的解决方案。
AWS 是一个很好的例子，说明了“自己动手”的身份验证解决方案如何工作，但是，当您谈论安全/身份验证时，自己动手通常是一个坏主意，除非您是安全/加密货币大师。
我的首选实际上只是使用客户端证书。它负责身份验证和安全过程。不需要 API 密钥，因为证书本身可以识别客户端用户。