As we’ve covered, basic authentication is a very easy standard to understand and implement. Simply send the user’s username and password as parameters in the HTTP request, and the provider site will verify the login credentials with every request, returning the requested resources if the credentials are authorized or an HTTP error response if not.
With any standard that is so easy to implement, you will invariably run into security or implementation concerns, and basic auth is no different. There are numerous reasons why you wouldn’t want to implement basic auth as your sole mechanism for securing protected resources. Let’s take a look at a few.
The primary reason against using basic authentication for securing private resources is that the client application needs to somehow store the user’s login information if it is to continue making requests on his behalf (i.e., without asking him for his username and password each time).
There are a few inherent concerns here:
First and foremost, as I have mentioned, every company or application that requests user login credentials needs to store that information, either for the current session or permanently in its database. Users trust that the company is properly encoding those values and has extensive security procedures in place to protect their information. But, unfortunately, there have been numerous cases where companies storing usernames and passwords haven’t used proper encoding practices (i.e., by storing login credentials as cleartext) and their databases have been hacked by malicious parties who then easily scanned the actual usernames and passwords stored within.
If the user changes his password, he will have to reauthenticate with the client application so that it can acquire the new login credentials. This means that any headless actions performed by the client application in the meantime (that is, before reauthentication) will fail.
These are just a couple of the fundamental issues in an authentication system that works with a user’s raw login credentials rather than a token-based, user abstraction system (which we’ll cover shortly).
The next strike against basic auth is that with every request to the provider site, the client application needs to send along the login credentials. This may not be as much of an issue if a user has a secure HTTPS connection with the provider site, which means he’s passing through encrypted versions of the credentials, but this is by no means the typical implementation.
It is often the case that the provider site with which the client application is communicating transfers data as unencrypted cleartext. This type of transfer system makes users vulnerable to malicious hackers, who can “sniff” the information being transferred to obtain a user’s login credentials.
With a token-based system, the provider (Yahoo!, Twitter, Google, etc.) issues tokens to the client application instead of just validating a series of login credentials. What this means is that the provider itself can track what tokens have been issued and to whom they were issued.
This token-based process has two very clear benefits:
The provider can display a list of all of the applications to which the user has granted access to his private information. This will allow the user to see where his information is being used and by whom.
The provider can revoke the user permission that allows the application to access his private information. Since the tokens are controlled and maintained by the provider, it essentially controls which applications have access to private information.
These benefits are not available when you use basic auth as your security mechanism. There is no way for a user to see which client applications are storing his personal information, and there is no way to revoke that access and delete the information from the application systems, unless the client provides that ability itself. In any event, this information is not centralized, so the user will have to recall all of the applications to which he provided his login credentials and work with them individually if he wants to modify that relationship.