Practical examples of authorizing a RESTful service?

Question

There are many excellent questions (and answers) on S.O. around the subject of REST and security. Many say "purists won't like this, but blah blah"... and then others says "you should never do that, because blah blah".

But I have not seen the solution that the "purists" are suggesting for the following scenario. So my question is - what are the "pure RESTful solutions" to the following scenario?

The simple scenario...

Imagine building a database/website that lets a user manage their favorite recipes. The website exposes a RESTful API so that users can query and manipulate their list from a custom program that they want to write (that utilizes this API).

So, user "A" has 3 favorite recipes with the ID's "1", "2" and "3".

User "B" has 2 favorite recipes with the ID's "4" and "5".

We need to make sure that if user A sends a DELETE command to /Recipes/4 that he will get a Forbidden (403) response.

What I would normally do...

What I would normally do is make them first call an authentication method, and send them some sort of auth-token that is valid for 30 minutes or so. Typically this token would be passed via a cookie.

What is the pure solution?

Is the pure REST solution to have them pass it as a variable in the query string? Are cookies the devil? Should the token be used as a segment of the URL (as opposed to a query string parameter)? Is there something else that answers this question clearly?

Answer 1

Pass the token in the authorization header. That's what it is designed for. See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-12.html

Answer 2

A simple stateless and cookie free solution would be giving each of your users an identical token.

There are ways to generate those tokens so that they are sparse enough for security concerns.

e.g. https://www.grc.com/passwords.htm

Suppose you have user A and user B. You generate a token X for user A and a token Y for user B.

So the user A will use something like /X/Recipes/1

and user B will use something like /Y/Recipes/4

It's safe because user A is the only one knows his token and as I mentioned before, the way you generate tokens can make sure it's "impossible" for others to guess that token.

So if someone else, like user B uses some other token in the url, say /Z/Recipes/1, you should be able to recognize and return a corresponding error message.

You can let user deliver the token in url, like I showed above, or embed it in HTTP request as Autherticantion message.

Answer 3

Treat the auth token as a resource.

You authenticate by GETting an auth token with parameters being credentials (basic auth over https for example).

Logout by DELETE'ing the auth token resource you got when logging in.