How I authenticate Application Programming Interface

Posted on March 17, 2014 06:26 pm

Yesterday I met a young upcoming computer programmer who asked me if it is possible to authenticate APIs using HTTP Basic Authentication that have become the standard way to authenticate over the web. HTTP API authentication has changed several times for the last decade or so. Since APIs became popular, a couple of methods have sprung up. Deviation from the specifications normally results in API consumers having to learn a new concept and sometimes they are forced to erase a pre-built library to work with new API.  The comparison of the cons and pros of secure ways of authenticating an API, is important. Here are my views on HTTP Basic Access Authentication over SSL and HTTP Digest. First if you can force the server to use SSL, or create a private API, then it’s Basic. HTTP Basic is a simple form of authentication where the client makes a request for information, sending a username and password to the server in plain text. After that, the server responds with the desired information or an error. My experience shows that HTTP Basic doesn’t need to be implemented over SSL and if you don’t, then it isn’t secure and from tests I have conducted in the past I won’t advise using it without.

There are plenty of negatives about SSL compared to basic HTTP. One of them is that SSL is slower to run than basic HTTP so this causes the clients to be slightly slower. Also, if you don’t have access to control client, and worse of all can’t force the server to use SSL as a developer you might not use SSL which will cause a security risk. In past tests that I have conducted, whenever I had the control of the clients, or when I ensured they use SSL, HTTP Basic was a formidable choice. I could only sort the slowness of the SSL by cancelling out the speed via making one request. Its simple to implement, so your client developers will have less work to do and take less time to deliver, so developers could be more likely to want to use your API On the positive side, you can store the passwords on the server in whatever encryption method you like, making the passwords more secure. In addition to that, one call to the server is needed to get the information, making the client slightly faster than more complex authentication methods might be. HTTP Digest access authentication is a more sophisticated form of authentication that works in different ways. First, a client sends a request to a server.

Then the server responds with a nonce and asks the client to authenticate. When the client responds with this nonce and an encrypted version of the password, username and a hash. After that, the server responds with requested information if client hash matches their hash of the username, password and realm or an error if not. The beauty of this is that no usernames or passwords are sent to the server in plaintext, making a non-SSL connection more secure than an HTTP Basic request that isn’t sent over SSL. The downside is that HTTP Digest is vulnerable to security attacks meaning it could be hacked and for every call needed, the client must make two, making the process slower than HTTP Basic. Unfortunately, HTTP Digest prevents use of the strong password encryption, meaning the passwords stored on the server could be hacked. HTTP Digest is prone couple of methods of hacking, especially where a server using strong encryption for passwords with HTTP Basic over SSL is not. My advice is that you store passwords on the server encrypted with strong password making it harder for hackers to extract them from the server.

Contador Harrison