Before getting into the age-old authentication dilemma, let’s start with an explanation of what authentication really is. Authentication and authorisation are, in fact, two different things that work together as a complete solution. Authentication refers to when a person is required to prove their identity as legitimate, and authorisation refers to permission to access certain resources. Basically, authentication relates to who you are, and authorisation relates to what you can do – simple.
But what exactly is basic authentication?
Basic authentication, or “basic auth”, is a widely used method for collecting username and password information. It works by passing an authorization header with the string basic, indicating that it uses the basic authentication scheme “Authorization: Basic <credentials>”. The credentials (username and password) are then transmitted over the network and encoded with base-64 and joined by a single colon “:”.
Basic authentication is the easiest way of implementing access controls on web resources as it doesn’t require any cookies, login pages or sessions – only the username and password. However, as it’s only encoded with base-64, there is no confidentiality mechanism in place to protect the credentials from being sniffed and decoded.
As well as basic authentication, there are other ways to implement authentication such as bearer authentication, form-based authentication, API keys and OAuth.
Bearer authentication is another HTTP authentication scheme that uses tokens instead of credentials for authentication, understood as “give access to the bearer of this token.” The bearer token is a cryptic string generated by the server in response to a login request. The client must send this token in the Authorization header to access any protected resources “Authorization: Bearer <token>”.
In some cases, the web application may use form-based authentication. Form-based authentication is not a formal standard of authentication, but a programming method of authentication used by developers to mitigate the risks associated with basic authentication. Most of the time, standard HTML form fields are used to pass the credentials in order to access the server. The server then validates the credentials and a session is tied to a unique key that is passed between the client and server.
Another common method used for authentication is API Keys. This is done by first generating a unique value and assigning it each user. This unique key may be generated using multiple criteria, such as IP address and location, or can be completely random by the server (but usually a long and unpredictable string). If a user wants access, they will need to provide their unique API key, and the server checks if it is the same key as before. A common precaution that API designers use is to make API keys for read-only data in to limit associated risks.
OAuth is a much newer, modern authentication scheme. Actually, there are two versions of OAuth: OAuth 1.0, first released in late 2007, and OAuth 2.0, released in late 2012. OAuth 1.0 provided a secure and strong mechanism of authentication but was ultimately replaced by OAuth 2.0 because it required a rather complicated implementation that was challenging for developers to implement.
By using OAuth, you can kill two birds with one stone as it’s used for both authentication and authorisation. OAuth is a delegation protocol, where a user grants access to an application to perform certain actions on the user’s behalf, access can be revoked if their actions become too suspicious, but this will depend entirely on the developer of the app. This simply means a secure third-party completes the transaction and can recognise any suspicious attempts at the transaction stage, and users can share their private resources with a third party whilst keeping their own credentials a secret.
As there are various authentication methods available, which exactly is the best? Honestly, it entirely depends on the situation. Most recommendations are usually OAuth due to its more secure nature, but it’s still possible to use basic authentication when properly configured. If the authentication situation for an application is not as security demanding, and the developers want a simple authentication standard, then they can still make use of basic authentication. However, always use an SSL encryption in combination with basic authentication to secure user account information being transmitted over the network. If the functionality of the intended application is basic, then basic authentication is the way to go.
So, is Basic Authentication too basic? Not really, no.