HTTP 身份验证与 cookie

Question

对于需要登录凭据的 Web 服务来说，基于 cookie 的身份验证似乎是当今的明确选择。

但是，如果您正在开发一个 Web 服务，其中客户端不是浏览器，而是通过 HTTP 访问资源的客户端软件（例如移动应用程序），您会使用 HTTP 身份验证还是 cookie 身份验证？

HTTP 验证：

• Web 服务器处理身份验证，因此在需要时更容易更改 Web 应用程序平台
• 自动应用于非代码资源（例如JPG、XML等）（问：有没有办法通过基于cookie的身份验证来做到这一点？）
• 更难将数据库存储的凭据与服务器身份验证（.htaccess/.htpasswd）集成

Cookie 验证：

• 细粒度的访问控制（代码资源可以根据凭据做出不同的响应）
• 控制会话过期（通过 cookie 过期）
• 完全掌控用户登录体验

我还遗漏了哪些其他考虑因素？还有其他优点/缺点吗？

这里有一些有用的讨论

Answer 1

通过 HTTP 身份验证，代码资源可以根据发出请求的用户做出不同的响应。用户名通常通过 HTTP 标头传递给代码。

通过 HTTP 身份验证，您仍然可以使用会话并获得它们带来的相同好处。事实上，会话窃取不再是一个大问题，因为您可以测试会话中存储的用户是否与通过 HTTP 身份验证进行身份验证的用户相同。出于同样的原因，会话标识符不必那么不可猜测，因为它们需要基于 Cookie 的身份验证。

Answer 2

好吧，当客户端是移动应用程序或不是普通浏览器的东西时，服务器应用程序仍然需要某种会话跟踪。执行会话跟踪的最简单方法是使用某种“cookie”，可以是标准 HTTP cookie，也可以是自定义会话 ID。因此，即使不使用标准 cookie 机制，会话标识符实际上也是一个“cookie”。我总是为客户端会话分配会话标识符，因此我倾向于投票支持 cookie 身份验证。

Answer 3

当密码被泄露时，HTTP 基本身份验证是一场噩梦，因为如果不首先更改所有合法客户端，就无法更改密码。您也不能强制单个用户取消身份验证，并且传输身份验证凭据的机制是不安全的（除非您将其包装在 https 中）

实际上，您最好的选择是使用基于 cookie 的系统，从而可以对各个经过身份验证的会话进行精细控制

Answer 4

现在似乎没有“HTTP 身份验证与 cookie”：如果我禁用所有 cookie，我的浏览器（Firefox、Opera、Chrome、Edge...）甚至都不会要求我进行 HTTP 身份验证。我猜这在某种程度上是反对 RFC 的。