How to implement a stateless REST API
Asked Answered
D

1

7

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?

Dobson answered 5/10, 2010 at 14:41 Comment(1)
I am still digesting this good article by John Wilander. Perhaps it can help you too. appsandsecurity.blogspot.com/2011/04/…Hereditament
C
10

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.

Cicerone answered 5/10, 2010 at 16:32 Comment(5)
Just to verify my understanding of this, the session token still requires session state on the server side? I.e., the lifetime of the session is managed by the server, and the token becomes invalid after a server-side session timeout? I'm looking for a way to accomplish a similar goal while having no concept of a 'session' on the server.Phlebotomy
This is also what i really dont understand. Everybody is talking about security and stateless but a session for the user has to be held on the server anyway.Overmatter
@gambo Why? The REStful services I build are secured and I don't have any notion of user session.Cicerone
But e.g. you are logging in from a client, the server is checking and providing you a authtoken(however it would look like). This authToken is sent everytime you make some requests to the server. So if somebody gets your request header the complete rest api is accessible isnt it? When is the authtoken invalid? For every request I need to check e.g. which user is behind this token and do some more security checks like if he has the right to edit this entry in the resource.Overmatter
@gambo There are some approaches to auth token that might require the server keeping some state that allows it to efficiently authenticate a token. As for someone stealing a token and re-using it. That's a valid concern and some token schemes have countermeasures for that. As I said, I'm no security expert so I have details off the top of my head.Cicerone

© 2022 - 2024 — McMap. All rights reserved.