Its impossible to have authentication without state. So when designing RESTful software with authentication do we compromise this architecture for the sake of secuirty? How far can this go? Can you store any amount of state as long as its in the effort of building a more secure system?
Representation State Transfer or REST has a number of core design concepts. One of the most important is that REST must be stateless or to quote Wikipeida:
"... A client in a rest state is able to
interact with its user, but creates no
load and consumes no per-client
storage on the servers or on the
network."
However, a usernames and passwords are by definition a state that unique to a client and is subject to change. Further more a client can have the state of being authenticated, or otherwise they would have limited or no access.
RESTful systems have two types of state. Client application state and resource state. The important thing about resource state is that it should have an identifier, like an URL.
Accessing resource state via a URL should return the same information regardless of who accesses it ( assuming sufficient authorization).
Server session state messes things up because people use it vary the contents of the response based on who is requesting the the resource. That makes bookmarking more tricky, sharing urls more difficult, caching more difficult.
Unfortunately the wikipedia quote is overly broad and open for misinterpretation. For me, the easiest way of thinking about it is that the server should have no knowledge about the current state of the client.
Authenticating a client does not require you to keep information about the client once they are authenticated. All that is required is that on the next request, you authenticate again.
SSL certificates wouldn't count as state, and they can be used for authentication as well as transport security.
They aren't practical for a typical user-facing web site, but they are used extensively for web services, including REST services, where the "user" is code that can load an X509 certificate and include it as part of the credentials on each request.
See this article for an example in C# with WCF.
Old question, but I believe that REST actually requires that the server must be stateless, in the sense that no data about the session is stored on the server.
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server
And there is in fact a way to achieve this. Have an authentication endpoint that returns a token. But instead of storing a random identifier in that token, store the primary key of your identified entity, followed by a cryptographic hash of the key, salted with a secret key not known to the client.
The server can now efficiently and securely authenticate you on every request. There is no session state on the server-side- the request contains all of the information needed.
In short: REST's statelessness states that state rests with the client ;)
Simply put, statelessness means in that each request that the client submits should contain all the information for the server to handle the request. Thus, without the need of prior state on the server.
Session state is kept on the client. The "hack" that is used in terms of authentication within REST is that session related information (state) can be captured as a resource which can be mapped back to the client session. For example start time, certificates, session ids with related information etc.
