A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] Use cookies with HTTP auth

SoniEx2
2020-08-25

When doing HTTP auth, just use cookies tbh.

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.

awwright
2020-08-27

Who is this a proposal for?

Aren’t cookies less secure?

SoniEx2
2020-08-27

what’s less secure: sending a plaintext password on every request to a compromised server, or sending a CSPRNG-generated access token?

awwright
2020-08-27

@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?

SoniEx2
2020-08-27

servers and browsers. servers so they set cookies, browsers so they do the password auth once.

collimarco
2021-02-24

You forgot all the REST APIs… It’s still useful for stateless requests.

SoniEx2
2021-02-24

Craft your own cookies. Or just send the whole thing in the request body.

Same level of security as HTTP auth, really.