Authorizing REST Requests

Question

I'm working on a REST service that has a few requirements:

1. It has to be secure.
2. Users should not be able to forge requests.

My current proposed solution is to have a custom Authorization header that look like this (this is the same way that the amazon web services work):

Authorization: MYAPI username:signature

My question is how to form the signature. When the user logs into the service they are given a secret key which they should be able to use to sign requests. This will stop other users submitting requests on their behalf, but will not stop them forging requests.

The application that will be using this service is an iPhone application, so I was thinking we could have a public key embedded in the application which we can do an additional signature with, but does this mean we'll have to have two signatures, one for the user key and one for the app key?

Any advice would be greatly appreciated, I'd quite like to get this right the first time.

Answer 1

I think the simplest way to do this right would be to use HTTPS client authentication. Apple's site has a thread on this very subject.

Edit: to handle authorization, I would create a separate resource (URI) on the server for each user, and only permit that (authenticated) user to manipulate this resource.

Answer 2

What's wrong with HTTP Digest Authentication?

Answer 3

There is a better discussion of this here:

http://stackoverflow.com/questions/7551/best-practices-for-securing-a-rest-api-web-service

Answer 4

The answer is simple: It cannot be done. As soon as you ship any solution to the end user, he or she can allways attack the server it is communicating with. The most common version of this problem is cheating with hi-score lists in Flash games. You can make it harder by embedding some sort of encryption in the client and obfuscating the code... But all compiled and obfuscated code can allways be decompiled and unobfuscated. It is just a matter of how much time and money you are willing to spend and likewise for the potential attacker.

So your concern is not how to try to prevent the user from sending faulty data to your system. It is how to prevent the user from damaging your system. You have to design your interfaces so that all damage done by faulty data only affects the user sending it.