I create a lot of little side projects and experiments. Sometimes I have an idea that would work best behind a login.
Building an entire login system from scratch can be a significant investment and creates a major barrier to entry. It’s prevented me from building useful tools because they would require a login.
But in 2022 I won’t let that stop me.
More than ten years ago I created a little experimental tool at work. We had a database of users but we didn’t have any type of API for our login system. If I built something that wasn’t part of the monolith, it wouldn’t integrate with the system. I decided to try HTTP Basic Auth. It worked, and that little experiment slowly expanded to dozens of other tools and became a major internal admin system. I’m not involved on the teams that use those tools anymore but my little auth module is still being used because Basic Auth has been good enough.
There are some very minor downsides, but if a project does well enough, I can always build a better login system later.
It would probably be strait-forward to implement a third party login flow, such as Google, Apple, or Facebook accounts. But, I have privacy and lock-in concerns with using these third-party systems.
What does HTTP Basic Authentication look like in 2022? Here’s a screenshot of the login prompt in the latest version of Google Chrome.
Some online resources mention that HTTP Basic Authentication is deprecated, but that’s a misunderstanding. Only passing username and password as part of the URL is deprecated. It’s still perfectly valid to pass the credentials in the HTTP header and that’s what I’ll be doing. This method works in every modern browser.
As an additional aside, modern browsers still support credentials in the URL, even though the practice is deprecated. To prevent certain fishing attacks, they hide those credentials from the user in various ways, but it tends to work anyway. I wouldn’t personally use credentials in the URL though; who knows how long browsers will continue to support that.
Because Basic Authentication sends the username and password with each HTTP request, it’s insecure unless the credentials are served over an encrypted HTTPS connection. These days HTTPS is the norm for many of our projects, but it’s something you need to be aware of. You don’t want to use this over a regular HTTP connection because anyone on the same network can see the unencrypted values. Because HTTPS requests are encrypted, this isn’t a problem over HTTPS.
I’ve created a template for a simple application that implements HTTP Basic Authentication in Go.
