This is the first article in a series about Authentication Strategies.
When a user visits a URL, they are kicking off a beautiful series of events to find a specific piece of content on the web. The server on which that content resides needs to know a few things about the user before it can send back the content. Anticipating this need, the browser sends a request with a set of HTTP Headers.
If the requested content is protected, one way for a browser to authenticate the request is by sending one or more authentication headers. What those headers look like will depend on your authentication strategy, but most of the time you’ll need an
Authorization header with a schemeand a set of parameters.
The Basic Strategy
Perhaps the simplest way to handle server-side authentication is with the basic HTTP authentication strategy. This simply means an
Authorization header uses a
Basic scheme with the Base64 encoded username/password provided as a single parameter.
How it works
When the user tries to access a protected resource, the server will look for the header and decode its credentials.
If the credentials are valid, the server sends a 200 response with the protected content. If not, it’s a 401.
The server can also send a
WWW-Authenticate header back to the browser, which will trigger the browser’s built-in dialog to enter a username/password to be sent back in a follow-up request with the encoded credentials.
The server will again try to validate the credentials, and this cycle will continue until the user is validated or the server refuses a connection.
Why you should use it
If you have a simple app where protected data doesn’t have major security needs, basic auth is probably fine. And it’s super straight forward and easy to set up.
That said, make sure you only use basic auth with HTTPS connections. Credentials sent over an insecure HTTP connection can be easily snagged and decoded by sneaky bad actors.
Why you shouldn’t use it
Basic auth is … well, basic. There’s no fancy encryption used to lock down credentials before sending them over the wire, and your server has less fine-grained control over user sessions than it might with other techniques.
Even with a secure connection, simply passing around Base64 encoded credentials can be risky. In the even that a bad actor intercepts the request, decoding is a breeze for anyone doing a quick search for decode Base64.
So if you’re looking for the most robust, secure or scalable authentication, you probably want to consider other options.