HTTP 基本身份验证在浏览器-服务器连接中使用不多，因为它在浏览器端涉及浏览器控制的登录弹出窗口，该弹出窗口总是很丑陋。这当然不适用于服务器-服务器连接，在这种连接中没有人类用户可以观察到任何丑陋，但它会导致普遍的不信任和不使用基本身份验证的气氛。

此外，在 1990 年代，在 SSL 出现之前，通过网络发送明文密码被认为是一种犯罪行为，而且愚蠢的是，人们认为像HTTP Digest这样的挑战-响应协议足以确保安全。我们现在知道事实并非如此。无论采用何种身份验证方法，完整的流量必须至少以加密方式链接到身份验证，以避免被主动攻击者劫持。所以 SSL 是必需的。但是当 SSL 生效时，在 SSL 隧道中“按原样”发送密码就可以了。因此，总而言之，SSL 中的基本身份验证对于严肃的目的来说足够强大，包括核发射代码，甚至与金钱相关的问题。

仍然应该指出，安全性依赖于中间人攻击的不可能性，在 SSL（通常使用）的情况下，这种攻击依赖于服务器的证书。SSL 客户端（在您的情况下为另一台服务器）必须非常小心地验证 SSL 服务器的证书，包括通过下载适当的 CRL 检查吊销状态。否则，如果客户端被重定向到假服务器，假服务器所有者将学习密码......从这个意义上说，使用 HTTP Digest 之类的东西会增加一些额外的缓解层，以防情况已经很糟糕，因为即使使用HTTP Digest，一个做中间人的假服务器仍然可以在任何时候劫持连接。

如果我们更进一步，我们可能会注意到，当使用基于密码的身份验证时，我们实际上想要基于密码的相互身份验证。理想情况下，SSL 客户端和 SSL 服务器应该根据他们对共享密码的了解来相互验证。证书有不必要的复杂性；理论上，SSL 客户端和服务器在这种情况下应该使用TLS-PSK或TLS-SRP，并完全避免所有 X.509 证书业务。

特别是，在 SRP 中，服务器存储的不是密码本身，而是它的派生词（具有一些额外数学结构的哈希）。需要注意一点：在 Web API 的情况下，客户端和服务器都是机器，没有人参与。所以，“密码”不需要弱到肉包能记住的程度。比如说，该密码可以是 25 个随机字符的序列，其中的熵已经超过了屋顶。这使得通常的密码散列方法（慢散列、盐）变得毫无用处。我们仍然希望避免将密码“按原样”存储在服务器的数据库中（因此作为潜在 SQL 注入的牺牲品），但是，在这种情况下，一个简单的哈希就足够了。

这指向以下几点：理想情况下，对于一个服务器使用的 RESTful API 与另一个服务器通信，基于共享（胖）秘密的身份验证，通信应使用带有 SRP 的 TLS。没有证书，只有存储在服务器上的哈希值。不需要 HTTP Basic Auth 或任何其他基于 HTTP 的身份验证，因为所有工作都已经发生在 SSL/TLS 级别。

不幸的是，当前部署支持 SRP 的 SSL/TLS 实施的状态通常意味着您还不能使用 SRP。相反，您将不得不在服务器端使用更普通的 SSL/TLS 和 X.509 证书，客户端会尽职地验证。只要验证正确完成，“按原样”发送密码就没有问题，例如作为 HTTP 基本身份验证的一部分。

HTTP 身份验证的一个主要问题是，除了关闭浏览器之外，没有其他方法可以注销。而且由于每个请求都带有密码，因此身份验证是无状态的。例如，您不能在 20 分钟不活动后注销用户。

像银行这样的高安全性网站通常会（总是？）不仅为用户提供手动注销的方法，而且还会在一段时间不活动后注销用户。这有助于防止许多机会性攻击。

实际上，我已经看到我的银行发送了这些请求。然而，他们仍然使用会话标识符，而不是每次都发送用户名和密码（我知道这不是很安静）。他们不只使用用户名和密码而是使用会话的原因是因为他们需要第二个身份验证因素。这意味着您需要为每次重新加载页面重新输入质询响应。

如果您的银行只是使用用户名和密码，那么老实说我不会在意它。但在我看来，任何自尊的银行应用程序都应该使用一种双因素身份验证形式：通过短信、读卡器、令牌......