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.
It happens in HTTP, before any HTML5 is rendered or even sent. Why have browser vendors neglected it? I suppose it's a chicken/egg problem. Nobody really uses it, so why spend effort on it? No effort is spent on it, so it's stuck in the 90s, why would anyone use it?
I've read it's partly for security. If browsers started to let you style and change the login UI then nothing is stopping bad-website.com from making it look like your bank's login site and fooling you. Yes you should be checking the URL, the SSL certs, etc. and not entering your password blindly... but real people don't do that even though they should. So the thinking is the browser will completely control the login form and make it super generic and obvious exactly what website you are logging into.
There isn't anything in the standard to support a "Go here to reset your password" link or a "Go over here to create an account" - I really appreciate HTTP auth for somethings - but it's not great if you don't have a user base that is registered for your site through some non-web based interaction. It's certainly possible to have a user creation flow that ends up auth'ing with Basic Auth but it's not particularly user friendly.
The browser could redirect the user to a form after cancellation or a certain amount of failures (say, 3 or 5) with recovery options. Add a nice retry button on there and you've got yourself a very simple login flow.
Stock nginx/apache configurations will basically let the user retry infinitely or show a plain error page after user authentication fails too often, but these pages are configurable and don't need to be handled by the web server itself.
One thing this mechanism doesn't provide is brute force protection through systems like CAPTCHAs.
Logging in and password recovery are two tasks that usually happen to extremely fatigued users. I'd like to briefly state that I absolutely loathe a lot of modern design decisions when it comes to authentication flow - the two page challenge system (first U/N then password) in particular provides an overly opaque login process that breaks a lot of password managers. That said - forcing the user to fail to auth before they can land on a page that lets them recover their password is a bad design. A lot of users know they've forgotten their password before they even try typing it. If it takes 3-5 failures to actually get the information on how to recover an account you'll lose a few users before the first failed attempt (they'll just walk away from your site) and most users by the time they've failed twice. Users have been trained that three failed login attempts can lock you out of an account - most will not just spam "blakdnasfnasnjsaja" into the password box three times in the hope that it gives them a forgot your password prompt... nearly none will do that five times.
On every page or widget you ask for authentication for you should have a clear nearby link that says "Forgot your Password?" this link shouldn't be in the standard information display text color (i.e. maybe black or a soft grey) and un-underlined because "it looks slick" - it should be obvious as hell, it's probably one of the best places to make sure of the old "color: blue; text-decoration: underline" styles[1] just so that users that are unfamiliar with your standard link coloration have absolutely no confusion.
I consider myself to generally not be a design oriented person, but I've seen this particular mistake cost so much business over my career that it is a hill I'm willing to die on. "Forgot your password" links need to be clear and constantly accessible - you should push back aggressively against anyone who wants to pop a little paper clip in there with a speech bubble of "It looks like you may be having trouble logging in" or anything else that deviates from those three words. When we're frustrated with a site we all just want to see "Forgot your password?" in blue and know immediately what we need to do - we never want to need to endure your design decisions or technical limitations to get there.
This component needs to be easy.
1. Ubisoft is a great example of this - they've got an extremely javascript laden login page for UPlay and yet "Forgot your password?" is written using that precise three word spell and is in "I'm a link from the 90s" blue - they decided to remove the underlining which is a frequent design decision these days (one I disagree with) but otherwise they're making it as blatant as possible https://account.ubisoft.com/en-US/login There's a bunch of stuff I'd complain about on this page (including the fact that on my browser on a 1080p screen I somehow end up with two different scroll bars) but it knows what's important.
If it takes 3-5 failures to actually get the information on how to recover an account you'll lose a few users before the first failed attempt
That's why you should also show the information when they cancel the prompt. Users will click the login link (because that's where password recovery is normally located), see a login popup, click close or cancel, and be greeted by a recovery page. No need to fill in fake info that way.
There's also no reason not to link to the recovery page! You could just as easily add a link underneath or next to the big green buttons that say "login" and "register". It all depends on how barren ("clean") you want your front page to be.
I abhor modern authentication systems (Google and Microsoft don't even show the password field next to the username field anymore for fuck's sake, you have to pass some kind of AJAX/Javascript validation logic), that's why I want authentication to return to the browser itself. There's a lot to be fixed regarding browser auth UI, most importantly better password manager integration, but taking auth flow control away from over-eager web designers can solve a lot of usability issues.
Browser auth is actually quite successfully implemented on mobile through U2F. I can click login, tap my thumb on the fingerprint sensor, get directed to a recovery/signup page if my device has no keys for that website or get authenticated automatically. On the desktop side TPMs should become available more often now that Windows 11 requires them (macs already have their own TPM implementation, of course). The quicker websites adopt this flow, the easier auth will become. That said, I've seen webauthn sites that don't ask you to validate your email after signing up, and that's a recipe for disaster, so the system isn't 100% perfect.
There's something to be said to only allow limited customisability when it comes to native browser controls. The window is native to the browser, so there shouldn't be any way for the website to make it appear as if the browser itself is stating something that the website is stating.
As a developer, the browser login popup follows your users' preferences rather than yours. That's also a net positive in my book.
A website that needs fallback support (for whatever reason) can always redirect to a web form login page that does little more than let you fill in your username/password and then navigate to https://user:password@website.com/. I don't know how well that works with authentication systems other than basic auth, but it's generally well-supported across the board.
The generic HTTP server error screen is merely an implementation detail. It's a result of people using HTTP Basic auth for a quick & dirty login mechanism rather than actually putting effort in.
This protocol combined with modern alternatives (like WebAuthn) should make for excellent accessible authentication mechanisms. It's a shame browser support is so mediocre (for example, password managers + HTTP auth can only work without user interaction) because the browser is perfectly capable of doing everything your usual boilerplate login page does.
As for SSO, the system supports Kerberos authentication, so using this rather than a custom HTTP login flow might actually make your users' lives a lot easier in some cases!
Nothing prevents serving this style of login from a front page that offers everything you just mentioned as an alternative. Groaning may express dismay but -- this is mere inconvenience we're dealing with here.
You can serve this style of login from a front page, but then the user gets the unstyled, limited context browser prompt before they see your site.
There's no button to create a new account or find a forgotten password. There's no reasonable way to logout. It's usable for a site with a trainable user base, like a small club or employees, but I wouldn't expect anything intended for public use to do it. I've experienced one public site that used it for its members only (subscription) content, but I think they've switched to forms and cookies.
the nice thing about this is that the browser will keep sending the credentials to subsequent requests of the same domain until it receives a 401 status as response.
The logout button can simply redirect to a static page that returns a 401.
How do you get the browser to send the Authentication header for every request thereafter? Typically you Auth once, and set cookies which the browser sends automatically with each HTTP request, even if the user is not on your domain.
You would have to rewrite HTML5 and handle all HTTP traffic manually to set the Authentication header for every request. OP's trick of HTTP + ancient browser spec for handling basic auth triggers automatic sending of the Auth header for all requests.
the nice thing about this is that the browser will keep sending the credentials to subsequent requests of the same domain until it receives a 401 status as response.
You don't need to set anything, just send a 401 if you want the browser to stop sending credentials. You don't even need cookies.
You could have a custom 403 page that allows a user to reset their password and has a contact form. You are right about the lack of SSO, but not everything needs to support SSO.
Comments
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.
Hm, why have browser vendors neglected the UX for this standard, no-cookie auth method? Why is there no corresponding markup in HTML5?
It happens in HTTP, before any HTML5 is rendered or even sent. Why have browser vendors neglected it? I suppose it's a chicken/egg problem. Nobody really uses it, so why spend effort on it? No effort is spent on it, so it's stuck in the 90s, why would anyone use it?
I've read it's partly for security. If browsers started to let you style and change the login UI then nothing is stopping bad-website.com from making it look like your bank's login site and fooling you. Yes you should be checking the URL, the SSL certs, etc. and not entering your password blindly... but real people don't do that even though they should. So the thinking is the browser will completely control the login form and make it super generic and obvious exactly what website you are logging into.
There isn't anything in the standard to support a "Go here to reset your password" link or a "Go over here to create an account" - I really appreciate HTTP auth for somethings - but it's not great if you don't have a user base that is registered for your site through some non-web based interaction. It's certainly possible to have a user creation flow that ends up auth'ing with Basic Auth but it's not particularly user friendly.
The browser could redirect the user to a form after cancellation or a certain amount of failures (say, 3 or 5) with recovery options. Add a nice retry button on there and you've got yourself a very simple login flow.
Stock nginx/apache configurations will basically let the user retry infinitely or show a plain error page after user authentication fails too often, but these pages are configurable and don't need to be handled by the web server itself.
One thing this mechanism doesn't provide is brute force protection through systems like CAPTCHAs.
Logging in and password recovery are two tasks that usually happen to extremely fatigued users. I'd like to briefly state that I absolutely loathe a lot of modern design decisions when it comes to authentication flow - the two page challenge system (first U/N then password) in particular provides an overly opaque login process that breaks a lot of password managers. That said - forcing the user to fail to auth before they can land on a page that lets them recover their password is a bad design. A lot of users know they've forgotten their password before they even try typing it. If it takes 3-5 failures to actually get the information on how to recover an account you'll lose a few users before the first failed attempt (they'll just walk away from your site) and most users by the time they've failed twice. Users have been trained that three failed login attempts can lock you out of an account - most will not just spam "blakdnasfnasnjsaja" into the password box three times in the hope that it gives them a forgot your password prompt... nearly none will do that five times.
On every page or widget you ask for authentication for you should have a clear nearby link that says "Forgot your Password?" this link shouldn't be in the standard information display text color (i.e. maybe black or a soft grey) and un-underlined because "it looks slick" - it should be obvious as hell, it's probably one of the best places to make sure of the old "color: blue; text-decoration: underline" styles[1] just so that users that are unfamiliar with your standard link coloration have absolutely no confusion.
I consider myself to generally not be a design oriented person, but I've seen this particular mistake cost so much business over my career that it is a hill I'm willing to die on. "Forgot your password" links need to be clear and constantly accessible - you should push back aggressively against anyone who wants to pop a little paper clip in there with a speech bubble of "It looks like you may be having trouble logging in" or anything else that deviates from those three words. When we're frustrated with a site we all just want to see "Forgot your password?" in blue and know immediately what we need to do - we never want to need to endure your design decisions or technical limitations to get there.
This component needs to be easy.
1. Ubisoft is a great example of this - they've got an extremely javascript laden login page for UPlay and yet "Forgot your password?" is written using that precise three word spell and is in "I'm a link from the 90s" blue - they decided to remove the underlining which is a frequent design decision these days (one I disagree with) but otherwise they're making it as blatant as possible https://account.ubisoft.com/en-US/login There's a bunch of stuff I'd complain about on this page (including the fact that on my browser on a 1080p screen I somehow end up with two different scroll bars) but it knows what's important.
That's why you should also show the information when they cancel the prompt. Users will click the login link (because that's where password recovery is normally located), see a login popup, click close or cancel, and be greeted by a recovery page. No need to fill in fake info that way.
There's also no reason not to link to the recovery page! You could just as easily add a link underneath or next to the big green buttons that say "login" and "register". It all depends on how barren ("clean") you want your front page to be.
I abhor modern authentication systems (Google and Microsoft don't even show the password field next to the username field anymore for fuck's sake, you have to pass some kind of AJAX/Javascript validation logic), that's why I want authentication to return to the browser itself. There's a lot to be fixed regarding browser auth UI, most importantly better password manager integration, but taking auth flow control away from over-eager web designers can solve a lot of usability issues.
Browser auth is actually quite successfully implemented on mobile through U2F. I can click login, tap my thumb on the fingerprint sensor, get directed to a recovery/signup page if my device has no keys for that website or get authenticated automatically. On the desktop side TPMs should become available more often now that Windows 11 requires them (macs already have their own TPM implementation, of course). The quicker websites adopt this flow, the easier auth will become. That said, I've seen webauthn sites that don't ask you to validate your email after signing up, and that's a recipe for disaster, so the system isn't 100% perfect.
There's something to be said to only allow limited customisability when it comes to native browser controls. The window is native to the browser, so there shouldn't be any way for the website to make it appear as if the browser itself is stating something that the website is stating.
As a developer, the browser login popup follows your users' preferences rather than yours. That's also a net positive in my book.
A website that needs fallback support (for whatever reason) can always redirect to a web form login page that does little more than let you fill in your username/password and then navigate to https://user:password@website.com/. I don't know how well that works with authentication systems other than basic auth, but it's generally well-supported across the board.
The generic HTTP server error screen is merely an implementation detail. It's a result of people using HTTP Basic auth for a quick & dirty login mechanism rather than actually putting effort in.
This protocol combined with modern alternatives (like WebAuthn) should make for excellent accessible authentication mechanisms. It's a shame browser support is so mediocre (for example, password managers + HTTP auth can only work without user interaction) because the browser is perfectly capable of doing everything your usual boilerplate login page does.
As for SSO, the system supports Kerberos authentication, so using this rather than a custom HTTP login flow might actually make your users' lives a lot easier in some cases!
Nothing prevents serving this style of login from a front page that offers everything you just mentioned as an alternative. Groaning may express dismay but -- this is mere inconvenience we're dealing with here.
You can serve this style of login from a front page, but then the user gets the unstyled, limited context browser prompt before they see your site.
There's no button to create a new account or find a forgotten password. There's no reasonable way to logout. It's usable for a site with a trainable user base, like a small club or employees, but I wouldn't expect anything intended for public use to do it. I've experienced one public site that used it for its members only (subscription) content, but I think they've switched to forms and cookies.
From the article:
The logout button can simply redirect to a static page that returns a 401.
How do you get the browser to send the Authentication header for every request thereafter? Typically you Auth once, and set cookies which the browser sends automatically with each HTTP request, even if the user is not on your domain.
You would have to rewrite HTML5 and handle all HTTP traffic manually to set the Authentication header for every request. OP's trick of HTTP + ancient browser spec for handling basic auth triggers automatic sending of the Auth header for all requests.
As the article states:
You don't need to set anything, just send a 401 if you want the browser to stop sending credentials. You don't even need cookies.
You could have a custom 403 page that allows a user to reset their password and has a contact form. You are right about the lack of SSO, but not everything needs to support SSO.
Responses for HTTP errors can be customized to include things like password reset and contacts. See e. g. https://nginx.org/r/error_page
The poor UX for HTTP authentication in browsers makes it a non-starter. I really like APIs that use HTTP authentication, however.