Authentication in RESTful web services

Question

I am currently creating a website which users can view and modify their widgets. All interation with the widget data stored on my server will be done through RESTful web ser

Answer 1

Is this not as simple as MACing the request to the web service?

So, you're providing the JavaScript that calls the web service, within this JavaScript you put a nonce. Unlike most nonce implementations, you have this live for the duration of the user session.

When calling the web service, the JavaScript in GetWidgets() uses the nonce as the key to hash some 'random' data, I'd probably use the time formatted as a string and the data, the user's id (12345) as the salt. The JavaScript then sends the hashed data and the unhashed time string as part of the web service call, but not the nonce. I'd then ensure the time that was sent was recent (i.e. last 20 seconds, limiting replay attacks) and that when the server hashes the time with the user id as salt with the nonce (that it knows because it set it) that it gets the same result.

So, we've used a shared key set by the server and sent to the client to act as the key for producing a hashed message authorization code (MAC or HMAC) but also prevented replay attacks (the MAC will be different for each request and has a very short replay window) and preventing session hijacking by not transferring any session information in cookies.

---

I've not come across your specific scenario before, but it does seem like a specific case of a generic problem of authenticating messages without wanting to send credentials with every message. MACing is reliably how I've seen this done.

See: http://en.wikipedia.org/wiki/Message_authentication_code, this gives a good overview on MACing and even includes a nice diagram to help explain. It's a fairly well trodden solution, the only deviation I'd recommend (because I've fallen foul of it) is to include the time in the message to prevent replays.

It's the basis of the approach used by Last.fm to help authorize access to their API, see part 8 on this page (Signing Calls): http://www.last.fm/api/authspec#8. The Hash they're using is MD5, the querystring is being included in the body text to be hashed and the secret being used a session key obtained from an initial authenticate call.