You could encrypt/decrypt the token in a cookie. You certainly wouldn't want to store it in plain-text.
Or, in your database, have username, password, and access token. The user enters their username and password to authenticate to you that they are that user. The "more secure" part of OAuth is that you aren't passing their credentials across the internet. On Thu, Oct 22, 2009 at 2:04 PM, soupreme <soupr...@gmail.com> wrote: > > Let's say that after a user "allows" and Twitter grants an access > token which I persist my app's db, what is the best design to > authenicate this user and match them to the stored token? > > If I use a browser cookie (hopefully not with the value of the user's > Twitter User Id which is public, lol) and this cookie is hijacked by a > third-party (let's say no SSL or I allow javascript to read the > cookie), isn't this hacker now authorized by Twitter with my > application knowing the difference since they aren't forced to login > and the access token doesn't expire? > > This seems a little insecure. Is anyone taking the time to identify > their apps users by a custom expiring token? Maybe I don't understand > Oauth enough. > > On Oct 22, 8:41 am, ryan alford <ryanalford...@gmail.com> wrote: > > Agreed. I think that's something a lot of people misinterpret. OAuth is > > for API authorization, not Twitter authentication. > > > > Ryan > > > > > > > > On Thu, Oct 22, 2009 at 9:35 AM, Andrew Badera <and...@badera.us> wrote: > > > > > Keep in mind too, OAuth is really for authorizing, not authenticating > > > ... may sound pedantic, but it's a pretty substantial difference. The > > > authentication stuff is more of an after thought ... > > > > > ∞ Andy Badera > > > ∞ +1 518-641-1280 > > > ∞ This email is: [ ] bloggable [x] ask first [ ] private > > > ∞ Google me:http://www.google.com/search?q=andrew%20badera > > >
