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'.

  • OAuth is essentially a combination of 2 and 3, but there are many implementations and helpers out there for you, which would allow for rapid testing... – Rowland Shaw Mar 15 '13 at 16:49
  • 3
    You might get better luck asking this question on security.stackexchange – ircmaxell Mar 15 '13 at 16:49
  • @RowlandShaw thanks for the advice. Assuming OAuth isn't possible at this stage... – Jamie Edwards Mar 15 '13 at 16:54
  • @ircmaxell Is cross-posting acceptable? – Jamie Edwards Mar 15 '13 at 17:00
  • @JamieEdwards you can flag it for the moderators to migrate... – Rowland Shaw Mar 15 '13 at 17:03

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.

| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.