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:

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:

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.



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:



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


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):


Jayakumar Jayaraman

Very nice article. Many thanks


I really appreciate it! Clears up a lot of things!


I have a question here, there is a scenario where you have to authenticate a user before sending the web service response. I am using spring security + digest + Active Directory Ldap for authentication.
The problem is that the comparisons of user entered password and the one stored in ldap is mismatching. This is because of the fact that we are applying salt + hash on plain password at client whereas salt + hash on encrypted password (stored in ldap).
Can you suggest a way to get this done?


** salt + hash on encrypted password (stored in ldap) on the server side.


Man-in-the-middle attacks can be prevented with HTTP Digest Authentication by extending it with some extra stuff (‘nc’ and ‘cnonce’). Ref:

I’m also not sure HTTP Digest Authentication really prevents you from storing strong encrypted passwords in the DB:
Why can’t you use bcrypt with digest auth? Can’t we apply bcrypt to the value sent by the client and then compare it to the database value (which also had bcrypt applied to it)?

Leave a comment: