Menu
I am working on a REST API that will be used by developers writing mobile apps. Users will be able to use 3rd party services (Google, Twitter etc) to authenticate themselves, this is mainly handled by OAuth (depending on the service in question). We use 2-legged OAuth between the client application and the API Server (where the consumer key/secret is app specific, the developer gets it from our site when the app is registered there).
My problem is how to handle to keep track of the user authentication in a stateless manner. I do not have the users credentials to send in each request. I could create a unique session_id when a user logs in and then require that in each request to the REST API. Are there any other solutions to my problem? Does using a unique session_id to identify the user cause any problems from a stateless REST API perspective?
340
REST APIs are stateless because, rather than relying on the server remembering previous requests, REST applications require each request to contain all of the information necessary for the server to understand it. Storing session state on the server violates the REST architecture's stateless requirement.
“Statelessness means that every HTTP request happens in complete isolation”. Application state is the information stored at the server side to identify incoming requests and previous interactions, REST statelessness means being free from the application state.
As per the REST architecture, a RESTful Web Service should not keep a client state on the server. This restriction is called Statelessness. It is the responsibility of the client to pass its context to the server and then the server can store this context to process the client's further request.
Disclaimer: I am not in anyway a security expert.
Don't call it a session_Id. Call it an authentication token and pass it the Authorization HTTP header using your own authentication scheme. See the Google AuthSub for an example.
Do not use this authentication token for anything other than identifying the user and determining if they are authorized to perform the request. Do not associate any state to the token and do not retrieve user preferences based on it.
199
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
