基于cookie的身份验证似乎是当今需要登录凭据的Web服务的明确选择。
但是，如果您正在开发一个Web服务，其中客户端不是浏览器，而是通过HTTP访问资源的客户端软件（例如移动的App），您会使用HTTP身份验证还是Cookie身份验证呢？
HTTP身份验证：
- Web服务器处理身份验证，因此在需要时更容易更改Web应用程序平台
- 自动应用于非代码资源（例如JPG、XML等）（侧面Q：有没有一种基于cookie的身份验证方法可以做到这一点？）
- 更难将数据库存储的凭据与服务器身份验证（.htaccess/.htpasswd）集成
Cookie认证：
- 细粒度的访问控制（代码资源可以根据凭据做出不同的响应）
- 控制会话的过期（通过Cookie验证）
- 完全控制用户登录体验
我还遗漏了哪些其他考虑因素？有其他优点/缺点吗？
Some helpful discussion is here
4条答案
按热度按时间oogrdqng1#
通过HTTP身份验证，代码资源可以根据发出请求的用户做出不同的响应。用户名通常通过HTTP头传递给代码。
使用HTTP身份验证，您仍然可以使用会话并获得它们带来的相同好处。事实上，会话窃取不再是一个大问题，因为您可以测试存储在会话中的用户是否与通过HTTP身份验证进行身份验证的用户相同。出于同样的原因，会话标识符不需要像基于Cookie的身份验证那样不可猜测。
rjzwgtxy2#
好吧，当客户端是一个移动的应用程序或不是普通浏览器的东西时，服务器应用程序仍然需要某种会话跟踪。执行会话跟踪的最简单方法是使用某种“cookie”，标准HTTP cookie或自定义会话ID。因此，即使不使用标准cookie机制，会话标识符也是有效的“cookie”。我总是为客户端会话分配会话标识符，所以我倾向于投票给cookie auth。
fnvucqvd3#
当密码被泄露时，HTTP基本身份验证是一场噩梦，因为没有办法在不首先更改所有合法客户端的情况下更改它。您也不能强制取消对单个用户的身份验证，并且传输身份验证凭证的机制是不安全的（除非您将其 Package 在https中）
实际上，您的最佳选择是使用基于cookie的系统，允许对单个身份验证会话进行粒度控制
zzlelutf4#
现在似乎没有“HTTP身份验证与Cookie”：如果我禁用所有cookie，我的浏览器（Firefox、Opera、Chrome、Edge等）甚至都不会要求我进行HTTP身份验证。这是某种对RFC的，我猜。