Monday, 26 February 2007
OpenID and REST doubts
« Firebug 1.0 | Main | Virtual machines »che bello, mi distraggo per un po’ e Microsoft, AOL e Digg adottano OpenID, mentre phpbb e wordpress ammiccano tramite mod e plugin.
Unless I’m missing something.
For a coincidence (I really don't remember what drove me to do it), a while ago I register to MyOpenID and so now I can identify myself as piccinini.myopenid.com and, trough delegation, as superfluo.org.
which, if no other, is pretty cool (in response to Tim Bray's What Could I Use It For Today? question ;-) ).
But I'm missing something about OpenID too and I'm going to share these doubts with my readers (have I readers??!!).
A short story: I discovered OpenID about 6 month ago while I was evaluating authentication methods for a new public web application. It immediately appeared to me as a very clever and exciting idea so I would be happy to adopt it. From another side, I wanted to follow a REST architectural style and these two requisites seemed to me very hard to conciliate and so, having already enough problems in my ToDo list, I gave up with OpenID.
Back to present, I still retain that it's a great idea but I wonder how can it be used RESTfully. Let me explain why in 4 steps:
- to obey the RESTful principles your application should be stateless;
- this means that you haven't a user session where to save authentication credentials;
- this, in turn, implies that you have to authenticate every request;
- if OpenId is part of the game, this means that for every request you have to contact an OpenId server to check the user credentials. In my opinion this is impracticable in most of the real situations.
Obviously I could be completely wrong, am I? In such case, how is it possible to use OpenID in a RESTful way? Back when I did my first evaluation I searched quickly (very very quickly, honestly speaking) but found nothing.
Technorati Tags: OpenID REST RESTful OpenID
Comments on this entry:
As far as I can tell, there's no way with the current specs to provide OpenID signon without using cookies, which is frowned upon from a REST purist standpoint. On the other hand, I think most REST practitioners would concede that cookies are okay if they're self-contained -- that is, they aren't simply a reference to some bit of server-side session state.
That's how I handle OpenID logins: when the OpenID is confirmed, I store it in a cookie (signed, in order to prevent tampering). That way, the OpenID server is only hit once, and the server side has no session state.
You've confirmed my suspects, that's too bad.
Anyway thank you very much for the hints
REST does not say the application has to be stateless but that the interactions have to be:
> All REST interactions are stateless. That is, each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it.
So if you use a session on the application side it does not matter from the REST POV. Using cookies is fine AFAIK because the HTTP request even with a cookie does not depend on the other messages flowing. The cookie is not a state per se but an attribute of the request. Well that's how I see it anyhow.
Ah! I'm still a REST novice and I must admit that I was a bit superficial in my learning. Thank you for the useful explanation.
Said that, there're arguments against cookies which are independent from REST, therefore it should be preferable if OpenID doesn't require to use them.
Instead it would be nice to have a sort of mix between digest access authentication and OpenID. I'm only envisioning it and I can't figure out the details. Maybe it's totally utopian.