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

  • John

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

  • Nitz

    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?

  • Nitz

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

  • Magne

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

  • soulmachine

    How about use oauth2?

  • Paulo Merson

    Nice post. How would you compare http basic, http digest with oauth 2.0?

  • Jan Wielemaker

    This was exactly the article I needed. Thanks!

    @magne: nope because the server doesn’t get the password from the client but the hash of it (actually twice with some additional strings appended to it, which the server does know). The server would have to send the salt and the client would have to do bcrypt. You have no control over that.

  • Yair K.

    Magne: The attempted protection against MITM is exactly why storing with strong encryption is problematic with Digest.

    It requires rehashing the plaintext password with a different salt each time. Since the client provides a nonce, and we can’t control that value (it could be anything), we can’t have the hash stored in the DB in advance. The only way to verify the value would be for the server to do the same MD5 calculation. Which means it mush start from plaintext password, do the same hashing and compare.

    So the password must either be stored in the clear, or the server must be able to decrypt it (and have a clear copy of the password in memory to start the verification with). This prevents use of hashing algorithm to store the password, leaving as with either plaintext or reversible encryption algorithms. The latter is more complicated to implement, and recovery of original password would be possible.

    (As an aside, note the only argument your link has against HTTPS+Basic is performance. Quite a few sites would rather lose a bit of performance than risk eavesdropping).

  • Ops

    you need to keep the password in plain text because you need to calculate the hash with the username and the nonce. if the password is encrypted, the hash will be different. the only solution would be the password being bcrypted on the client and hashed, however, as far as it is responsibility of the browser, might be complicated to perform…

  • Thanks a lot for the talk Mark. Really useful for me , as I run an seo company reviewing site