Answer 1

Answer 2

这是一个老话题，我不相信最高投票/选择的答案是正确的。

如@Nateowami所述，security stack exchange thread概述了许多基本身份验证问题。

我想指出另一个问题：如果您正确进行密码验证，那么基本身份验证会使您的服务器更容易受到拒绝服务攻击。为什么？在过去，人们普遍认为盐渍哈希足以进行密码验证。 That is no longer the case。如今，我们说你需要具有缓慢的功能来防止在数据库暴露的情况下暴力强制密码（这种情况经常发生）。如果您使用的是基本身份验证，则会强制您的服务器在每次API调用时执行这些缓慢的计算，这会给您的服务器带来沉重的负担。只是通过使用这种过时的身份验证机制，您就更容易受到DoS的攻击。<​​/ p>

更一般地说，密码的价值高于会话：用户密码的泄露允许无限期地劫持用户的帐户，更不用说劫持用户因密码重用而访问的其他系统的可能性;而用户会话是有时间限制的，并且局限于单个系统。因此，作为深度防御的问题，如果没有必要，不应重复使用密码等高价值数据。基本身份验证是一种过时的技术，应该弃用。

Answer 3

大多数网站更喜欢OAuth而非Basic Auth的原因是Basic Auth要求用户在第三方应用中输入密码。此第三方应用程序必须以明文形式存储密码。撤消访问权限的唯一方法是让用户更改其密码。但是，这会撤消所有第三方应用的访问权限。所以你可以在这里看到问题所在。

另一方面，OAuth需要一个网络框架。用户在此特定站点本身的登录页面上输入其登录信息。然后，该站点生成一个访问令牌，应用程序可以使用该令牌在将来进行身份验证。优点：

• 可以撤销访问令牌
• 第三方应用无法看到用户的密码
• 可以授予访问令牌特定权限（而基本身份验证则平等对待每个消费者）。
• 如果第三方应用程序变得不安全，服务提供商可以决定撤销为该特定应用程序生成的所有访问令牌。

Answer 4

在可以被嗅探的环境中通过http的基本身份验证就像没有身份验证一样，因为密码可以很容易地被反转然后重新使用。响应上面关于ssl上的信用卡“有点”更安全的讽刺评论，问题在于在同一频道上反复使用基本认证。如果您破坏密码一次，则会损害该通道上每个事务的安全性，而不仅仅是单个数据属性。

如果你知道你会一遍又一遍地通过网络会话传递相同的信用卡号码，我希望你除了依靠SSL之外还想出一些其他的控制权，因为这可能是一种信用使用的卡号经常会受到损害......最终。

Answer 5

Answer 6