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?

Andreas
  • 638
  • 2
  • 8
  • 14
  • 2
    I am still digesting this good article by John Wilander. Perhaps it can help you too. http://appsandsecurity.blogspot.com/2011/04/rest-and-stateless-session-ids.html – RayLuo Apr 17 '13 at 13:58

1 Answers1

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.

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • 1
    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. – Aron Feb 10 '11 at 20:24
  • 1
    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. – Gambo Aug 25 '11 at 12:12
  • 1
    @gambo Why? The REStful services I build are secured and I don't have any notion of user session. – Darrel Miller Aug 25 '11 at 12:58
  • 1
    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. – Gambo Aug 25 '11 at 13:10
  • @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. – Darrel Miller Aug 25 '11 at 13:23