There’s no good reason to keep sending the user’s plaintext password with literally every request. The benefit of HTTP auth is that you can use non-plaintext methods like challenge-response, but we ditched those with the move to TLS. As such there’s literally no benefit to HTTP auth nowadays, other than being unable to save passwords/integrate with password managers. If you can call that a benefit.
and if you’re wondering why I haven’t joined the group (the one on w3.org), blame this.
Who is this a proposal for?
Aren’t cookies less secure?
what’s less secure: sending a plaintext password on every request to a compromised server, or sending a CSPRNG-generated access token?
@SoniEx2 There’s other authentication methods that allows the client to send a value computed from a limited-duration access token and a nonce. You can’t do anything like that with cookies.
But, who is this a proposal for?
servers and browsers. servers so they set cookies, browsers so they do the password auth once.
You forgot all the REST APIs… It’s still useful for stateless requests.
Craft your own cookies. Or just send the whole thing in the request body.
Same level of security as HTTP auth, really.