RESTful authentication as a form of state

Question

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.

Answer 1

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.