HTTP Basic Auth Explained

Maybe you have stumbled among a page like this in the past:

What you are presented with here is probably the simplest way to password-protect your website - and it's baked right into the HTTP protocol: Basic Auth. Let's have a look at it in detail.

The protocol

1. The user requests a site, in our case /secretPage
2. The server realizes, authentication is required and responds with status code 401 Unauthorized. Moreover, the WWW-Authenticate-header is set to request auth. Realm is just the name of the restricted area (here Secret).
3. The browsers job now is to obtain the users credentials in some way. They could already be stored or a form could be displayed, prompting the user to enter them.
4. To send the credentials back to the server, they are formatted as username:password and Base-64 encoded.
5. The client performs a GET-request with the authorization header, its type (Basic) and the string created in (4.).
6. The server validates the credentials and returns either OK or an 401-error.

Implementation

So, the protocol itself is very - as the name suggests - basic. Implementation is also very easy: e.g., on an Apache web server, you just need to create a .htaccess and .htpasswd file in the directory to be protected (see apache.org). What can also be considered a plus: there is no need to create your own login UI: most browsers already provide you with one.

Drawbacks

While Basic Auth is easy to implement, it also just offers basic security:

• Username and password are send on every request, increasing the risk of a man-in-the-middle attack.
• The password is transferred unencrypted. Therefore, when using Basic Auth, you totally rely on transport layer security.
• The password needs to be validated on every request - this operation can become expensive in high-usage scenarios.
• No logout-flow.
• The login fields provided by the browser are easy to implement, however, they make every site look the same. This is not only a UX-issue, but also potentially problematic when it comes to phishing attacks.

Should I use it?

Probably not - there are better, more advanced options. However, if you just want to secure an area on your personal homepage or an API-endpoint, which is only used by a single script - go for it.