Is request signing (digesting the request body) in a REST API necessary?

Question

I am currently engaged in a debate and I wondered what the community's opinion on this was.

1. We see REST APIs which just require basic authentication (perhaps HTTP) or OAuth.

2. We see REST APIs which also require a signature; containing secret(s), time stamp, perhaps a nonce.

3. We occasionally see REST APIs which also require the request parameters (assembled in a specific way) to be included in the signature.

Number 3 offers full-fat security (although in reality and practice is there much wrong with the former?), however, it adds more implementation complexity - assembling the request parameters in a specific way creates a big opportunity to mess things up, and you can say goodbye to 'quickly testing' the API.

My security head would say 'go with number 3, idiot', but my usability head says 'that's a complete PITA, number 2 is plenty sufficient in the real world and if it's used properly - i.e. over https - there's nothing to go wrong'.

Answer 1

From the server, you may want two things:

1. to make sure that the client sending the request is indeed who they claim;
2. to be able to prove to third parties that whoever sent a given request is indeed a specific client entity.

Digital signatures are more-or-less needed to achieve the second goal. For the first goal, simple authentication is enough; HTTP "Basic Authentication", played within SSL (HTTPS), is sufficient. Your "type 2" method is a kind of authentication which relies on a client certificate; another equally good method, and simpler to activate, is to use client certificates at the SSL level (the SSL libraries then handle the nonce-timestamp-signature business themselves).

Neither method 1 or 2 yields a proof which could be used during litigation. Authentication convinces the server that the right client is at the other end of the line, but the server gets nothing which could convince a judge. For that, you really need a signature on the request itself, i.e. your "method 3". It is not that method 3 is "more secure"; rather, method 3 provides an additional functionality which may or may not be useful to your specific case.

Also, note that having a signed request does not completely replace authentication, if only because of replay attacks.

Answer 2

If the server is talked with using HTTPS (with only trusted certificates!), there is no direct reason to use any of the more complex methods. A simple plain-text password basic authentication is sufficient and secure.

If the communication channel is not trusted, for example if allowing for company man-in-the-middle SSL proxies or untrusted certificates, all the parts of the request should be included in the "signature", including some form of replay protection. Also, the "signature" must not reveal the authentication secret.

The point Thomas raises about provability of client requests is a good one. However, the "signature" in most REST APIs I have come across is not a signature at all - it is a symmetric authenticator that lends nothing towards provability (the same authenticator can be and must be computable by the server).

So unless you actually have client certificates for the clients, the method for making sure the client is indeed who they claim is of little relevance.