On: Common REST Mistakes

[telemachos]

Since a number of people have mentioned point #6 (Sessions are irrelevant), I have a question: Can anyone point to a concrete, more detailed discussion of how to do authentication and authorization in a RESTful manner?

I may be missing something very obvious, but I just don't see how this should/can/might look. (Just to be explicit, I'm not trolling. I'm confused.)

[carpo → telemachos]

One way to do this is to have the clients pass the authentication information in the headers with every request.

[derefr → telemachos]

Basically, http://en.wikipedia.org/wiki/Digest_access_authentication#Ex... but with anything you like in place of the GET.

[kmt → derefr]

Is the well known and used cookie based authentication in conflict with REST? In my mind it's not, it's orthogonal to it.

If not logged in, redirect to a login page (resource) which upon success redirects back, e.g. GET login?next=desired_resource.

If logged in but not authorized to perform the action on the resource return 401.

That's it basically, isn't it? Also not trolling, challenge me if I'm missing something please.

[daredevildave → kmt]

Cookie-based authentication is generally only applicable to the browser interface. From my point of view where REST really shines is at the API level. HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) is good at the API level where you send your credentials with each request.

[derefr → daredevildave]

> HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues )

You know, with all the little browser-chrome experiments that have been going on lately, I'm really surprised that no one has tried to make HTTP-authentication-based login/logout/account management as painless as HTML-served variants. I'd imagine that it would couple with the little "lock" icon in the URL/status bar, making it have four states instead of two: "insecure, secure, insecurely logged in, and securely logged in" where clicking on it brings up a menu to both view credentials and change your password/edit profile/log out/close account/sign up/anything else browser makers want to implement. (They could be distinct, of course, but I like the idea of making "insecure" look scary so that users would be deterred from sending credentials through it.

[kmt → daredevildave]

What if you have to serve both interactive users and automatic clients? Would you use the url structure for both or would you have a separate api structure?

[steveklabnik → telemachos]

If you know Ruby, you could check out AuthLogic.

[gthank → telemachos]

The HTTP spec includes the Basic and Digest methods of auth.