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.
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.
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.
As a developer, the browser login popup follows your users' preferences rather than yours. That's also a net positive in my book.
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!
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.
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.