Storing OAuth AccessToken and authenicating user...

Oct 22, 2009 at 5:42 PM
Edited Oct 22, 2009 at 6:07 PM

I probably don't know enough about  Oath, so probably a stupid question, but in the WebOAuthAuthorization example, the comments read that the AccessToken granted by Twitter after a user "allows", should be persisted in the application's database.

This makes sense as this token never expires (unless explicitly revoked by Twitter or the user). So here's my question. Which is more of a design question more than anything.

If an application authenicates a user based on some application provided unique key saved in a browser cookie (hopefully not the Twitter User ID which is publically available, lol) then uses this key to identify and match to the user's db stored access token, doesn't this pose a security issue should the cookie be hijacked (maybe lack of ssl or javascript attack)?

Should an application be designed to persist the AccessToken in the db (am I correct that it is in the format [UserId-AccessToken]) but authenicate a little more securely by some expirying token stored as a cookie?

This is my first time running the Linq2Twitter code so sorry, but any ideas would be appreciated.  Thanks.

 ** Let me clarify that I really don't want to force my users to have a user/password for my application in addition to having to "allow" with Twitter.  I really hate that.

Oct 24, 2009 at 1:38 PM

The access token is no good without its associated access token secret, which should never be transported without HTTPS protection.  

If you want your users to implicitly have an account with you as soon as they authorize Twitter, Twitter has an OAuth API for allowing that.  From that point on, users log into your web site by being logged into Twitter.  It's sort of like OpenID, except it's Twitter's proprietary login API that uses OAuth instead.

Dec 4, 2009 at 10:59 AM

Thanks for your help!