How to do REST securely and with sensitive data?

Question

Hello, we are implementing a new web service. The web service will be a store of sensitive data and there are multiple users types with different permissions. So some user types can't access(and some can't change, and so on) certain types of data. How would this work in REST? I'm very new to REST, so sorry if this sounds noobish.

Answer 1

Your first step is to provide some transport encryption in the form of SSL. This should take care of ensureing there are no man in the middle attacks and that nobody is snooping the data. Second you'll need to figure out some sort of authentication method. A popular method is to create a login service to which you send a user name and password and it returns some sort of a limited life key. You then send this key along with all subsiquent requests and the server validates it before returning any data. If you have different user levels then as well as checking the key also check if the given user should be able to access that information.

Answer 2

No matter what you will probably want to encrypt it with HTTPS.

The client can simply include the username and password in every request.

Or you can have a logon request that authenticates the user and returns a session state token in a cookie or as part of the response.

Answer 3

As the first poster states, it is a popular model to provide a means for clients to first authenticate against your system (google do this for a number of their apis). The reply to which includes a token for the client to include as a parameter on subsequent requests.

e.g. HTTP POST (over SSL) to http://you/auth with username and (MD5 hash of password) - compare this to the MD5 of the password you have stored for them.

Respond with HTTP 200 OK and a message body or header with your authentication token.

This has a twofold benefit over resubmitting auth credentials with each request. There is as reduced processing overhead for the token (now just a validity check - possibly against an in-memory store of valid tokens) rather than a DB lookup for user and password. You also reduce the number of times the credentials are sent over the wire (albeit encrypted thanks to SSL).

Implementing access control on your resource endpoints will require a bit more work but is fundamentally just a specifying which tokens can be used against which resources. This will vary depending on your scenario.

Hope this makes sense, and good luck.