views:

329

answers:

2

I just started looking into OAuth and it looks really nice. I have oauth with twitter working in ruby right now.

Now I'm wondering, what is the recommended safe way to store the responses in my local database and session?

  • What should I store?
  • Where should I store it?

This example twitter-oauth-with-rails app stores a user.id in the session, and the user table has the token and secret. But that seems like it'd be really easy to hack and get the secret by just passing in a slew of test user ids, no?

+1  A: 

If you're developing a web application you can add a hidden field to the form the user submits, with some hash-like value calculated with the user.id so evil guys cannot change that value and just "guess" for an access token

Pablo Fernandez
+1  A: 

The tokens are useless without the consumer key/secret of your twitter app as they're not the same for every app but depend on the consumer key/secret.

To get a session variable you would have to guess the session id which is not that easy to accomplish.

If you want you can store those tokens in the session but I would suggest storing the user tokens in your database with all the other user data so your session contains only the data to identify the user in your system.

Update: I'm not sure if I understand correctly what you mean by accessing the tokens from the database by guessing an ID.

Do you have any authentication in place so that the users have to enter some credentials to access their data? You should store the tokens the same way you store the users email address or password and only authenticated users should be able to access it.

Tomas Markauskas
thanks, this is helpful. I am just trying to really grasp the best way to do this because many people have said to never store _any_ confidential data in the session. but it seemed like it might be possible to access a user model from the database by id if it was in the session, _if_ the developer left something exposed. something like that.
viatropos
The session data is not accessible for the user as they only know the session id but not what's stored in the session. The only way to access the session data for another user is to use session hijacking but it's not just replacing one small number with another. See here: http://en.wikipedia.org/wiki/Session_hijacking
Tomas Markauskas
If you think about it then there's no other way to tell which user the session belongs to as you can only use cookies and that's just what sessions do but more secure than just storing the user id in the cookie.
Tomas Markauskas