5

We have a REST application that is utilized mostly by applications that dont need to maintain their state, so till date we have been quiet "RESTFUL" without maintaining a state. We use the Private/Public (similar to Amazon) for authentication.Currently the client passes the credentials for every request

Now we have a new requirement where we have to maintain the state (or conversation).The client can be a Rich application or a hand held device .I am trying to comeup with the best way to implement the state .Should we pass on a session Id and maintain that ID ..is that the best and the only solution ?

romanianGeek
  • 51
  • 1
  • 2
  • 2
    Why can't the RIA or handheld maintain a session and get resources from your REST server? Why break the core rules of REST? Why not push stateful session where it belongs -- in the human interface? – S.Lott Mar 23 '10 at 19:20
  • Good question , are you fine with the credentials being sent across every request followed by authentication ..that seems to be the clincher for some of my guys in the team – romanianGeek Mar 23 '10 at 20:13
  • Authentication can easily be cached server side and inflict almost zero performance penalties. – Gandalf Mar 23 '10 at 20:15
  • @romanianGeek That's the way the Authorization header is meant to be used. Each http request should stand on its own. If you are requesting a resource that requires authorization then send it. – Darrel Miller Mar 23 '10 at 20:48
  • @Gandalf What do you mean by "cached server side"? If you are "caching" something on the server side that correlates with a particular client then you are in effect holding session state. How do you match client requests with the information cached on the server. – Darrel Miller Mar 23 '10 at 20:49
  • What kin dof state are you talking about? Can you provide more context? – Jan Algermissen Mar 24 '10 at 11:18
  • @Darrel Sorry, should have been more clear. Using the Auth header for say an LDAP lookup (or PKI certificates) you can cache the response from the LDAP and on subsequent client requests simply return the cached object rather then making a call out to the authentication mechanism. really has nothing to do with REST or how your RESTful service is implemented. I am only talkng about the performance penalty of having to "authorize" on every request rather then keeping cookies/session state. – Gandalf Mar 25 '10 at 14:05

1 Answers1

3

Passing on a session ID is not the only way and not the best way to maintain conversational state. The best way, if you have a RIA is to maintain the state on the client itself, where it belongs, as some of the comments suggest. This means still sending the credentials every request.

Re-authentication on every request is the only way, and if you feel that there's a performance hit on the server, the server can (as suggested) cache the result of an authentication request for a period of time. Digest authentication could help avoid caching responses by cryptograpically signing the tokens going over the wire.

If that's not good enough you could use something akin to Google ClientLogin, and giving the client an encrypted token that can be verified without needing to ask an authorization, and without passing the user's real credentials over the wire. Google themselves this by doing the login over https, and then using the generated tokens over http. It's open for replay attacks for the lifetime of the token.

mogsie
  • 4,021
  • 26
  • 26