OAuth's tokens and sessions in REST

Question

The other minute I read an article on OAuth. It described especially the tokens being exchanged between client and service provider during a series of requests.

The article also mentioned that OAuth gains significant popularity in RESTful APIs as authorization layer. As I understood, REST should be kept completely stateless.

The question: Doesn't this repeated token exchange torpedo REST's "being stateless" principle? IMHO the tokens can be seen as a kind of session ID, can't they?

Brisco

Answer 1

OAuth tokens are explicitly a session identifier, interaction is not stateless between requests in the OAuth token negotiation protocol as the requests must be performed in a specific sequence, and they do require per-client storage on the server as you need to track things like when they were issued. So yes, OAuth does violate the strict principles of a RESTful architecture.

Unfortunately there's the Real World^TM to contend with where we need to do things like allow applications to authenticate on the behalf of individuals without requesting their password, which OAuth does fairly well. It would be impossible to implement a similarly secure authentication scheme without this kind of state. Indeed, one of the changes required by OAuth (1.0a) was to add more state to the token negotiation protocol to mitigate a security risk.

So, does it torpedo REST's stateless principle? Yes. Does that matter? Not unless you live in an ivory tower :-)

Cancellate

I like the Real World (TM). Thanks for the answer! – Brisco

Once OAuth authentication has been processed, however, it can be effectively stateless -- the OAuth token is stored by the client and is sent along with each REST request in the Authorization header. – Concuss

@Jordan: OAuth token is saved on server to avoid re-authentication, so the state is saved on both client and server. So it is stateful. Greg sums it up rather nicely. – Gibbie

@johndodo, that's the difference between 2-legged and 3-legged oauth. 2-legged is evaluated fresh on every request and so it can be stateless (from the API perspective, clients may still store credentials for re-use) where 3-legged involves the generation, persitence and lookups for session tokens and so can never be completely stateless. – Hecker

Answer 2

Authentication is a state that must be tracked somehow when dealing in web interactions. Ultimately if your app is restful or not, the server must be able to track each users "authenticated state" and unfortunately that requires some kind of circumvention of the underlying stateless nature of HTTP and any additional transports/techniques (like REST) on top of it.

Hence to develop any kind of authenticated app, a principle of state must be shoe horned in somewhere, and if that so happens to be OAuth on top of REST, thats how it must be!

Discussion