RESTful thoughts - OAUTH and statelessness

I keep a copy of Roy Fielding's 162 page dissertation in my laptop bag, yeah I know - ich bin ein nerd, but hey it only adds another 2~3 lbs to my bag and I like rules and architecture - "form follows function" as Fielding puts it.

I am facing an architectural paradox right now where form seems to be tripping over function - client-stateless-server (CSS).

One component of the REST definition is that it must be stateless as defined by the principle of client-stateless-server - check out section 3.4.3 of his document.

Here's the rub: the OAUTH protocol defines patterns to pass tokens back and forth (also recommending that the tokens have an expiration set on them) as well as store nonce for signature and URI uniqueness. If these things are stored / retrieved / used by the Server application (i.e. the RESTful API), doesn't it seem that the client becomes more bound to the server; especially when the authentication / authorization is part of the payload. The separation of concerns is no longer afforded to the client - it removes the benefit of CSS; just as Fielding describes stateless as being paramount to visibility, reliability, and scalability.

Now you're going to ask about the key and secret for OAUTH. Those things are different - while they are stored on both the client and server they are evaluated per request within the context of that request. Whereas a token (Access or Request) gets evaluated and attached to a user or that user's hypermedia and the like. Feels a bit like "session" - something that can expire, holds info about or can be tied to a user.

I maybe splitting hairs but I feel that in order for an application to be stateless each request from the client to the server must contain all of the information to properly understand the request. The tokens have meaning on the server more than just a being token.

I absolutely love the RESTful architectural style and the OAUTH protocol. But can the two work together without breaking the rules?

Generally you'd want to abstract authentication from your application. OAUTH addresses both authentication (am I who I say I am) and authorization (can I do what I am trying to do) - so meaning is given to the token passed between the applications.

Honestly this incongruity between the two patterns will not stop me from using both together, I am not sure it's worth loosing the functionality of form - as fielding puts it:

Like most real-world systems, not all components of the deployed Web architecture obey every constraint present in its architectural design. REST has been used both as a means to define architectural improvements and to identify architectural mismatches. Mismatches occur when, due to ignorance or oversight, a software implementation is deployed that violates the architectural constraints. While mismatches cannot be avoided in general, it is possible to identify them before they become standardized.