How to authenticate APIs – HTTP Basic vs HTTP Digest
A comparison of the pros and cons of the three main secure ways of authenticating an API, in plain business terms. We cover:
- HTTP Basic Access Authentication over SSL
- HTTP Digest
The answer, as usual, is it depends, but if you can force the server to use SSL, or are creating a private API, then its Basic.
HTTP Basic Access Authentication over SSL
HTTP Basic is a simple form of authentication where:
- STEP 1 - the client makes a request for information, sending a username and password to the server in plain text
- STEP 2 - the server responds with the desired information or an error
HTTP Basic doesn’t need to be implemented over SSL, but if you don’t, it isn’t secure at all. So I’m not even going to entertain the idea of using it without.
Pros
- 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
- Unlike Digest, you can store the passwords on the server in whatever encryption method you like, such as bcrypt, making the passwords more secure
- Just one call to the server is needed to get the information, making the client slightly faster than more complex authentication methods might be
Cons
- SSL is slower to run than basic HTTP so this causes the clients to be slightly slower
- If you don’t have control of the clients, and can’t force the server to use SSL, a developer might not use SSL, causing a security risk
In summary - if you have control of the clients, or can ensure they use SSL, HTTP Basic is a good choice. The slowness of the SSL can be cancelled out by the speed of only making one request.
HTTP Digest Access Authentication
HTTP Digest access authentication is a more complex form of authentication that works as follows:
- STEP 1 - a client sends a request to a server
- STEP 2 -the server responds with a special code (called a nonce), another string representing the ‘realm’ and asks the client to authenticate
- STEP 3 - the client responds with this nonce and an encrypted version of the username, password and realm (a hash)
- STEP 4 - the server responds with the requested information if the client hash matches their own hash of the username, password and realm, or an error if not
Pros
- 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. This means SSL isn’t required, which makes each call slightly faster
Cons
- For every call needed, the client must make 2, making the process slightly slower than HTTP Basic
- HTTP Digest is vulnerable to a man-in-the-middle security attack which basically means it could be hacked
- HTTP Digest prevents use of the strong password encryption, meaning the passwords stored on the server could be hacked
In summary, HTTP Digest is vulnerable to at least 2 methods of hacking, where a server using strong encryption for passwords with HTTP Basic over SSL is not.
If you don’t have control over your clients however they could attempt to perform Basic authentication without SSL, which is much less secure than Digest.
The answer - it depends, but probably HTTP Basic
Ideal:
- Use HTTP Basic with SSL, slower than non-SSL, but only one call needed per information request
- Store passwords on the server encrypted with a strong password hash such as bcrypt, making it harder for hackers to extract them from the server
- Force the server to serve the API over SSL
If you can’t force the server to server the API over SSL, and don’t have control over all the clients being built (i.e. you are creating a public API):
- Use HTTP digest