HTTP 身份验证与 cookie答案

【问题标题】：HTTP authentication versus cookiesHTTP 身份验证与 cookie
【发布时间】：2011-06-24 08:12:25
【问题描述】：

现在看来，基于 cookie 的身份验证是需要登录凭据的 Web 服务的明确选择。

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

HTTP 身份验证：

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

Cookie 验证：

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

我还遗漏了哪些其他注意事项？还有其他优点/缺点吗？

Some helpful discussion is here

【问题讨论】：

如果对这两种身份验证之间的安全性感兴趣，请阅读：stackoverflow.com/questions/5052607/cookies-vs-basic-auth/…

标签： apache http cookies authorization

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

通过 HTTP 身份验证，您仍然可以使用会话并享受它们带来的相同好处。事实上，会话窃取已经不是什么大问题了，因为您可以测试存储在会话中的用户是否与通过 HTTP 身份验证进行身份验证的用户相同。出于同样的原因，会话标识符不必像基于 Cookie 的身份验证那样难以猜测。

【讨论】：

好点。但是，您说“会话窃取”不是问题。您是指嗅探 HTTP 数据包并复制会话 cookie 吗？似乎 HTTP 身份验证同样易受攻击，因为 user:pass 在easily decodable Base64 中传输。如果通过 HTTP 传输，窃取 HTTP Auth 凭据只会稍微困难一些。还是我不明白你的意思？
使用 HTTP 身份验证时，会话标识符几乎没有用处（因为在 Web 应用程序启动并有机会查看会话标识符之前，他就被网络服务器拒绝进入）。攻击者还必须知道用户名和密码。另一方面，要获得授权，用户名和密码必须在每个 HTTP 请求上传输。所以是的，数据包嗅探与基于 Cookie 的身份验证一样危险。我说的是诸如共享带有会话标识符的链接之类的事情。

【解决方案3】：

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

确实，您最好的选择是使用基于 cookie 的系统，允许对单个经过身份验证的会话进行精细控制

【讨论】：