Using www-authenticate for user authentication

  • Funny that old things like basic HTTP auth are regularly rediscovered by developers.

    There are also other flavours of authentication that can be used in this context, like Digest, supported by all major browsers and only sending hashed passwords (even on plain http connections).

  • I always thought you couldn't implement logout with HTTP basic auth, but according to this:

    > logging out is done by simply returning a 401 without www-authenticate header

    I did not know that worked!

  • I see an authentication pop-up and groan. If I leave it there it'll time out, if I hit 'escape' or my login fails I'll get some generic HTTP server error screen. No password reset box, no contact form, no OAuth/SSO login button.

  • I won't get tired of mentioning this - the basic authentication dialog should show a message from the server that is supposed to inform you what kind of credentials to enter. This is super useful for intranets, spam prevention systems and other stuff. Chrome removed this message years ago because of a dubious security report, and Firefox appears to have finally given in and removed it as well. All because someone could MITM your connection and present a login prompt à la "please enter your YouTube credentials" (completely ignoring that if they MITM you, they could serve you a page that really looks like a login page). This change completely ruined the usability of basic authentication.

  • The big problem with this is that mobile Safari on iOS won't autofill passwords for sites using WWW-Authenticate. It used to, but that feature got dropped years ago, which really ticks me off, as I regularly use a couple of sites that use it.

  • If this is new to you, you can also include the username and password in the url:

    https://user@example.com/page

    https://user:pass@example.com/page

  • Looking at the MDN page [1], I noticed that SHA2-256 digest authentication was added relatively recently to Firefox (and Firefox for Android). I wonder why they added it, as no other browser manufacturer seems to care and the added benefit of using digest rather than basic auth is only minimal now that every decent website has TLS.

    Also, interestingly, the support matrix suggests that Firefox for Android supports Kerberos and NTLM authentication. I guess I never expected Kerberos for websites to show up outside of desktop browsers.

    [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WW...

  • what a coincidence I just wrote about this last night on my blog - https://blog.aawadia.dev/2022/02/17/basic-auth-with-javalin/

  • I don't understand why "no cookies" is listed under "pros". This works exactly like a session cookie (a header attached to every request to the domain), the only difference is that the header contains your actual plain-text credentials instead of a token. It is at most as secure/safe/non-invasive as a cookie, and in a lot of situation, a lot less.

    The obvious way to improve it would be to offer a way for the browser to load a custom form to authenticate and get the (hashed) credentials to present to the original website in the header. And then you have recreated session cookies in full.

  • Having to do an authentication check on every request is suboptimal, but ok in many cases. It's just very unfortunate that more protocol explicitly directing secure interactions between the user and the user-agent in managing identity and authentication never really emerged.

  • There's also NTLM and Negotiate (Kerberos).

    https://caniuse.com/?search=www-authenticate

  • What is the deal with no capitalization? It is distracting because it is almost as if the writer went out of their way to do this while leaving most other grammar intact.

  • Why is this preferable to authentication using cookies?