Programming Social Applications

The Reasons Against Using Basic Authentication

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 client needs to store login information

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 ...