HTTP 身份验证与 cookie
对于当今需要登录凭据的 Web 服务来说，基于 cookie 的身份验证似乎是明智的选择。
但是，如果您正在开发一个 Web 服务，其中客户端不是浏览器，而是通过 HTTP 访问资源的客户端软件（例如移动应用程序），您会使用 HTTP 身份验证还是 cookie 身份验证？
HTTP Auth：
- Web 服务器处理身份验证，因此在需要时更容易更改 Web 应用程序平台
- 自动应用于非代码资源（例如 JPG、XML 等）（侧面问：有没有办法使用基于 cookie 的身份验证来实现此目的？）
- 更难将数据库存储的凭据与服务器身份验证 (.htaccess/.htpasswd) 集成
Cookie 身份验证：
- 细粒度访问控制（代码资源可以根据凭据做出不同的响应）
- 控制会话过期（通过 cookie 过期）
- 完全控制用户登录经验
我还遗漏了哪些其他考虑因素？还有其他优点/缺点吗？
It seems that cookie based authentication is the clear choice today for web services that require login credentials.
But what about if you're developing a web service where the clients are not browsers, but client software (such as a mobile App) that accesses resources via HTTP, would you use HTTP authentication or cookie authentication?
HTTP Auth:
- Web server handles authentication, so easier to change web app platform if needed
- Automatically applied to non-code resources (e.g. JPG, XML, etc) (Side Q: Is there a way to do this with cookie-based auth?)
- Harder to integrate database-stored credentials with server auth (.htaccess/.htpasswd)
Cookie Auth:
- Fine grained access controls (a code resource can respond differently based on credentials)
- Control over expiration of session (via cookie expirations)
- Full control over user login experience
What other considerations am I leaving out? Any other Pros/Cons?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
通过 HTTP 身份验证，代码资源可以根据发出请求的用户进行不同的响应。用户名通常通过 HTTP 标头传递给代码。
通过 HTTP 身份验证，您仍然可以使用会话并获得它们带来的相同好处。事实上，会话窃取不再是一个大问题，因为您可以测试会话中存储的用户是否与通过 HTTP 身份验证进行身份验证的用户相同。出于同样的原因，会话标识符不需要那么不可猜测，因为它们需要基于 Cookie 的身份验证。
With HTTP authentication, a code resource can respond differently based on the user who made the request. The name of the user is usually passed to the code via HTTP header.
With HTTP authentication, you can still use sessions and have the same benefits that they bring. In fact, session stealing is not that much of a problem anymore, because you can test whether the user that is stored in the session is the same that authenticated via HTTP authentication. For the same reason, session identifiers need not be that unguessable as they need to be with Cookie based authentication.
好吧，当客户端是移动应用程序或不是普通浏览器的东西时，服务器应用程序仍然需要某种会话跟踪。执行会话跟踪的最简单方法是使用某种“cookie”，可以是标准 HTTP cookie，也可以是自定义会话 ID。因此，即使不使用标准 cookie 机制，会话标识符实际上也是一个“cookie”。我总是为客户端会话分配会话标识符，因此我倾向于投票支持 cookie 身份验证。
Well, when client is a mobile app or something that is not an ordinary browser, a server app still needs some kind of session tracking. The simplest way to perform the session tracking is to use some kind of "cookies", either standard HTTP cookies or custom session IDs. So, a session identifier is effectively a "cookie" even when a standard cookie mechanism is not used. I always assign session identifiers to client sessions, so I tend to vote for cookie auth.
当密码被泄露时，HTTP 基本身份验证是一场噩梦，因为如果不首先更改所有合法客户端，就无法更改密码。您也不能强迫单个用户取消身份验证，并且传输身份验证凭据的机制是不安全的（除非您将其包装在 https 中）。
实际上，您最好的选择是使用基于 cookie 的系统，从而允许对单个经过身份验证的用户进行精细控制会议
HTTP basic auth is a nightmare when the password gets compromised, as there's no way to change it without changing all the legitmate clients first. You also can't force an individual user to be deauthenticated, and the mechanism for transmitting the authentication credentials is insecure (unless you wrap it in https)
Really, your best option is to use a cookie based system, allowing granular control over individual authenticated sessions
现在似乎没有“HTTP 身份验证与 cookie”：如果我禁用所有 cookie，我的浏览器（Firefox、Opera、Chrome、Edge...）甚至都不会要求我进行 HTTP 身份验证。我猜这在某种程度上是反对 RFC 的。
Seems there is no "HTTP authentication versus cookies" nowadays: none of my browsers (Firefox, Opera, Chrome, Edge, ...) even asks me for HTTP authentication, if I disable all cookies. That's some kind against the RFCs, I guess.