[mLuby]

> We just need to take away the developer's choice and force them to integrate

Who's we? Who are they integrating with? A protocol? A business? A government?

This has been tried in a multitude of ways. There's always a bit too much friction or cost.

[c4mpute]

Also, all the standards were crap.

HTTP got basic auth, which is crap because plaintext password transmission happens, also the browsers never got around to implement any sensible UI (e.g. you cannot log off). Then it got digest auth, which at least wasn't plaintext in transmission, but required plaintext password storage on the server. Then came negotiate, which only worked with some proprietary products, had even worse UI and was unusable outside a company's internal net.

Alongside that, there was HTTPS client auth, where, instead of fixing known problems, standards devolved into "sorry, we don't support that anymore". Also, the UI was crap.

Alongside that, there are homegrown methods using web forms, cookies, a lot of spit and maybe some javascript, which everyone uses atm. Everyone rolls their own, because over decades, standard bodies couldn't get their shit together. Also, everyone suffered from the corresponding attacks on all the weak and broken homegrown crap out there.

There is friction and cost, but those come from a lack of trying and a lack of giving a fuck by the people building web browsers, web servers and web standards. They basically declared the problem solved after the invention of cookies.

[singpolyma3]

Since everything is TLS now, basic auth no longer transmits in the clear. But I agree browser vendors have refused to bother putting in even the bare minimum of effort for years. I've been subscribed to the firefox ticket to allow http auth logout for my entire adult life.

[ape4]

Maybe before we die ;)

It would be cool if the challenge could specify the URL of an image to appear in the login dialog.

[mjec]

> HTTP got basic auth, which is crap because plaintext password transmission happens...

Plaintext submission happens with HTML forms too. The problem with Basic is the password goes with every request. That means you're exposing a long term credential to a higher risk. We want to exchange the long term credential for a short term one, ideally scope limited. That is far less catastrophic to revoke, and gives you some power of granularity (you can at the very least have some operations prompt for the password again). It also means you can limit risk on the server: only one page has access to the long term credentials, which can be more easily audited, or even hosted on dedicated servers.

WebAuthn has been the real savior here. Real cryptography has always been desirable for this, and removing per-site passwords is honestly just a bonus.

[c4mpute]

Imho WebAuthn is just the next problematic non-solution: Everything you do in WebAuthn you have to build up manually within the already-problematic forms+cookies+serverlogic+javascript stack. You cannot just instruct your webserver to do WebAuthn for /secret and everything works, no, you need tons and tons of code for it to work. Code that will have errors and problems. Code that is lots of complications on top of forms+cookies+serverlogic+javascript.

WebAuthn might solve a problem for the likes of Google and Facebook. But definitely not for the average web developer or server admin. And not for the user of some HTTP-based API. And the problem WebAuthn solves isn't really "we need better Auth", it is rather "we need better customer lock-in". Because the complexity and incompatibility of WebAuthn will just reproduce the debacle that was OpenID, only with the added "bonus" of being coupled to some hardware.

[waste_monk]

>also the browsers never got around to implement any sensible UI (e.g. you cannot log off)

FWIW in firefox you can go to "clear recent history" and then uncheck everything but "active logins". This will wipe out any currently logged in basic auth.