Why sign REST queries even when using SSL?

Question

I've just read this very interesting article: Principles for Standardized REST Authentication and I'm wondering why one should sign REST queries even when using SSL. In my understanding, signing REST queries lets the server ensure requests come from trusted clients.

Having said that, is signing really necessary considering that SSL also protects against man-in-the-middle attacks?

Answer 1

As stated on the Wikipedia article for HTTPS:

[...] HTTPS provides authentication of the web site and associated web server that one is communicating with, which protects against man-in-the-middle attacks. Additionally, it provides bidirectional encryption of communications between a client and server, which protects against eavesdropping and tampering with and/or forging the contents of the communication. In practice, this provides a reasonable guarantee that one is communicating with precisely the web site that one intended to communicate with (as opposed to an imposter), as well as ensuring that the contents of communications between the user and site cannot be read or forged by any third party. [...]

This is why you need HTTPS, so that the client "is sure" that it's requests are sent to the proper destination. The article you linked also says this:

If you are not validating the SSL certificate of the server, you don't know who is receiving your REST queries.

But HTTPS normally does not authenticate the client unless you configure the server to request a certificate from the client in order to perform mutual authentication. If you read the comments in the post you linked you will see people mentioning this:

If you are going to use https, why not use it fully, and ask for client side certificates too? Then you get a fully RESTful authentication method, because the client and the server are authenticated at the connection layer, and there is no need to bring authentication into the URI level.

But HTTPS with client-side certificates is more expensive and complex so most API providers keep "the normal" HTTPS to identify the server and use a lighter mechanism to identify the clients: the API keys. The API keys basically consist of a name which is public - for example "Johnny" - and a secret key which is private - for example a long string of randomly generated characters.

When you make a request to the server you include the name "Johnny" in the URL so that the server knows who sent the request. But the server doesn't just blindly trust you that you are "Johnny", you have to prove it by signing the request with the secret key which, because it's private, only the real "Johnny" knows.

Answer 2

A digital signature has legal implications such as non-repudiation, which any value transaction should require. It's not just a matter of authentication. A digital signature on an actual transaction is a much stronger piece of evidence in court than 'this conversation was carried out over SSL with mutual authentication so it must have been the defendant Your Honour'.