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 services. For example, if a user wants to see a list of their widgets the flow of execution would be something like:

1. User 12345 accesses https://www.example.com/Login.htm and authenticates with the server (in my case through an OpenID provider)
2. User 12345 then accesses the page https://www.example.com/Widgets.htm
3. Server responds with an HTML page and javascript that will be used to access my web services.
4. When the HTML page has loaded the javascript function getWidgets() will be called. getWidgets() will call my web service https://www.example.com/Services/Widget/12345
5. The service responds with a list of the users widgets which another javascript function renderWidgets(widgets) will update the html page

I don't want anyone else but user 12345 accessing their own widgets so I guess getWidgets() will have to provide some authentication to my web service. I'm not sure what the best way would be to achieve this.

I was thinking that the client and server could have a shared secret that getWidgets() will send to the web service. The server could generate this secret as random string (number, GUID or whatever) and include it in the response header when the client requests the initial HTML page. The client would use this secret key when sending requests to the server.

Does this sound like a sensible idea?

This is a common requirement so is there a standard way of achieving the same thing? As far as I am aware this is outside of the scope of OpenID and OAuth would not be suitable.

Thanks in advance.

Answer 1

This is a great question - but I think your solution may need to be a bit more complex than you are thinking.

In general, the way in which you want to authenticate this kind of scenario is in a 2-stage handshake. The first step is for your application to provide the server a private key (generated by the server, unique to the client application) to authenticate that it is, in fact, a valid client. This is what provides authoritative evidence to your server that the request is coming from software it knows and can trust.

The second step, then, is that when a user goes to log in to your client application, they provide a username / password combination. This information, along with your application key, should all be sent up to the server via SSL.

SSL encrypts the data so that a third-party with a packet-sniffer can't read the data in-transit, and the server does the following:

1. Checks that the application key is valid.
2. Validates that the username exists, and is associated with the application.
3. Encrypts the password and tests the encrypted version against the encrypted version in the database, associated with the username.
4. IF ALL of the above-listed checks pass, the server returns a session ID, which can be put into a client-side cookie - and used to re-authenticate the user on each subsequent request. IF ANY of the tests fail - the server returns a 401: Unauthorized response, or other similar error.

At this point, the client can utilize the returned session ID without having to continue to re-submit the application key.

Your Application

Now, in your case, you may be actually hosting the client/server in the same application and on the same server. In this case - you can generally skip all of the pieces revolving around the private application key - and simply disallow cross-site script requests instead.

Why? - because the thing you're really protecting against is the following:

Server A hosts your RESTful API. Client's B, C and D host clients which will rely upon Server A's API. What you don't want is for Client E (not your application - and malicious) to be able to access Server A either by bypassing or stealing the credentials of one of the other Clients.

If, however, both client and server are hosted in the same place, and therefore have the same URL - i.e. the RESTful API resides at www.yourdomain.com/api and the client resides at www.yourdomain.com/ - you can generally just not allow any AJAX type requests which originate outside of yourdomain.com - and that is your layer of security.

In this case, the following is all you should need to do to have a reasonable level of security:

1. Enable SSL for your server.
2. Only allow requests to /auth/login (or whatever your login POST method is) to come via SSL (in C# this can be done by using the [RequireHttps] attribute on the method or controller).
3. Reject any AJAX requests which originate outside your own domain.
4. Use a layer of encryption in your cookie.

What should your cookie contain?

Ideally, the cookie should contain 2-way encrypted data that ONLY your server can decrypt. In other words - you might put something like the user's username or user_id inside the cookie - but 2-way encrypt it using Rijndael or another cryptography system - using an encryption password that only your server has access to (I suggest a random string of characters).

Then - when you receive subsequent requests with the cookie attached, you can simply do the following:

1. If the cookie exists, attempt to decrypt it using your private password.
2. If the resulting decrypted data is garbage - throw a 401: Unauthorized response (this is an altered or fake cookie)
3. If the resulting decrypted data is a username which matches your database - you now know who is making the request - and can filter / serve them data accordingly.

I hope this helps. :) If not - feel free to post any comments and ask questions, and I'll try to clarify.