验证Http请求（REST、Xml over Http）的当前标准是什么？

该标准应解决以下身份验证难题，如-

重放攻击 中间人 明文攻击 字典攻击 强力攻击 假冒服务器欺骗

我已经看过Amazon Web服务，这是一种可能性。更重要的是，似乎有两种最常见的方法：

使用apiKey，其编码方式与AWS类似，但它是请求的post参数

使用Http AuthenticationHeader并使用类似于AWS的签名

签名通常通过使用加密的共享密钥对日期戳进行签名来获得。因此，此签名将作为apiKey或in进行传递 Http AuthenticationHeader

我想知道社区的两个选择，他们可能使用了一个或多个，也希望探索其他我没有的选择

---

考虑到。我也会使用HTTPS来保护我的服务。

我不确定是否有一个标准。如果有，则可能是HTTP Auth（基本或摘要）。上述两种解决方案都非常糟糕

AWS是一个很好的例子，说明了“滚动您自己的”身份验证解决方案是如何工作的。然而，当您谈论安全/身份验证时，滚动您自己的身份验证通常是一个坏主意，除非您是安全/加密专家

我的首选实际上只是使用客户端证书。它负责身份验证和安全过程。不需要API密钥，因为证书本身标识客户端用户

“认证”是指： 证明我你就是你说的那样

“您是谁”是实体（个人、计算机用户、软件、服务器等）的身份

“标识”是每个实体唯一的属性（dba在这里称为主键）

所以你必须以某种方式证明你有这种独特的属性。 当这里的实体是HTTP客户机时，HTTP Auth是向服务器证明其唯一身份（由我们所称的用户名表示）的标准化方法

它不涉及通道的安全性，这正是表示层（即SSL）的用途，并且要求各部分之间共享机密。“共享秘密”意味着双方都必须知道，其他人不知道。这意味着双方相互信任，不泄露秘密，或者在秘密被泄露时采取适当措施（例如更改秘密）

HTTP作为一种协议，不包括进行授权的其他方式，并将其留在其他层。例如，SSL可以通过使用公钥基础设施（证书和证书颁发机构）证明双方的身份，而无需共享秘密

最后：

• 如果可以在双方之间共享机密，则可以使用HTTP Auth进行身份验证，并使用SSL保护通道。由各方安全地交换和存储共享的秘密

• 如果您不想共享机密，但双方可以约定一个共同的受信任的第三方，您可以使用纯HTTP和SSL来保护通道，并使用PKI（>证书）证明一方或双方的身份

• 还有许多其他的可能性，但这两个是我所能想到的最标准的，应该与大多数现有的HTTP软件/库/什么的兼容

• 家用brew系统虽然在技术上是有效的，但可能会违反公认的标准，或者是在应用层实现的特殊（因此是非标准）系统（以解决应在另一层解决的问题，bah）

---

如果不同意共享秘密（并对其保密），或者不同意信任其他人来处理该唯一性（PKI），就无法证明某事物的唯一性。其他一切都只是实施细节。

谢谢您的帖子。我们正在使用IIS。同意，没有统一的标准。最流行的方法可能是基本的HTTP身份验证——但请确保始终将其与SSL配对。它只有使用SSL才是安全的，没有SSL它是高度不安全的。另请参阅