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
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:
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:
/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).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:
401: Unauthorized
response (this is an altered or fake cookie)I hope this helps. :) If not - feel free to post any comments and ask questions, and I'll try to clarify.