What to do with the access token after you've received it

[shawninreach]

Im a little confused on why some people are saying you want to store
the access token after you get it. Dont you just want to keep it in
the session until the session expires or the user clears cookies? I
understand how to use the access token, im just confused on after the
session is expired your going to need to make the user click "I Allow"
later again and theres nothing that can be done about that and you
request new tokens so why store them in the database at all. Basically
im just trying to understand this process a bit more so I can safely
store only what I absolutely need to. Thanks guys for the help!

[JDG]

Access Tokens, in Twitter's case, do not expire. According to the OAuth spec, they MAY expire, but do not have to. In Twitter's case, it seems they have decided to keep an access token valid until the access granted by said token is explicitly revoked by the user. Fetching a new access token in every session is not performant, and would require the user to approve access every time they signed in to your app.

--
Internets. Serious business.

[ryan alford]

The access token doesn't expire. It's also specific for the user.
There is no reason for you to get rid of it.
You should store it with a relation to the username. The user should
not be forced to re-allow every session.

On Oct 21, 2009, at 7:44 PM, shawninreach <shawni...@gmail.com>
wrote:

[shawninreach]

Not sure if what I posted made sense. Basically i understand now why
to store the access token, just curious now on how a user that
connects to your app on a different computer authenticates to the
point where we believe they are a given user, then we can grab the
access token from the db and keep going. Is there an authenticate
method that just asks for the users user and pass, if correct i can
pass the access token and thats all instead of having to say "I Allow"
for this app again?? ty for being patient every1.

On Oct 21, 8:08 pm, ryan alford <ryanalford...@gmail.com> wrote:
> The access token doesn't expire. It's also specific for the user.
> There is no reason for you to get rid of it.
> You should store it with a relation to the username. The user should
> not be forced to re-allow every session.
>

> On Oct 21, 2009, at 7:44 PM, shawninreach <shawninre...@gmail.com>

[shawninreach]

Ok so you guys are saying store the access token in the db. Im getting
hung up on how you would authenticate this user at a later point
without making them reauthenticate through twitter to make sure who
they say they are.

First Authentication
User comes to site -> twitter auth (type in username/pass) -> twitter
auth (do you want to allow app) -> back to site (store access tokens)

Later Authentication on a diff computer per say
User comes to site -> twitter auth (type in username/pass) -> ?? (do
something with access token) ?? -> back to site
Something like if user and pass are valid then get the access token
from the db and start doing w/e you wanted to do? Is this the flow
that im missing?

On Oct 21, 8:08 pm, ryan alford <ryanalford...@gmail.com> wrote:

> The access token doesn't expire. It's also specific for the user.
> There is no reason for you to get rid of it.
> You should store it with a relation to the username. The user should
> not be forced to re-allow every session.
>

> On Oct 21, 2009, at 7:44 PM, shawninreach <shawninre...@gmail.com>

[JDG]

You could have the user sign in with their username and password and make a call to account/verify_credentials. If it returns 200, you know you can get the access token.

--
Internets. Serious business.

[shawninreach]

Yeah exactly what i was thinking but i thought this was the whole
point of oauth to not need someones pass to authenticate with an app.
Oauth is basically just a setup where it authenticates an app to use
an account, but its not something that I can use to implement a full
login system to my own app?

[JDG]

That's true, it does violate one of the tenets of OAuth. In your case, saving the access token may not be the most ideal solution, for the simple fact that you apparently ONLY deal with Twitter and you expect logins from multiple systems. You could either require OAuth at every step using "Sign in With Twitter" that would only require the user to approve access once, but would fetch a new access token every time, or you could create your OWN user system with a different user/password combination.

--
Internets. Serious business.

[Andrew Badera]

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

[ryan alford]

Agreed.  I think that's something a lot of people misinterpret.  OAuth is for API authorization, not Twitter authentication.

Ryan

[soupreme]

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
>

> > On Wed, Oct 21, 2009 at 10:16 PM, shawninreach <shawninre...@gmail.com>

> > >> Internets. Serious business.- Hide quoted text -
>
> - Show quoted text -

[ryan alford]

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.

[soupreme]

I see. Thanks! It sort of makes me emo to have to manage seperate
credentials. Looking for more of a SSO solution, but thats cool.

Interesting tho, Twitter is putting a lot of trust in the third-party
app that they won't mismange tokens. At least it's better than basic
auth. Thanks again.

> > > > ∞ Google me:http://www.google.com/search?q=andrew%20badera- Hide quoted text -

[shawninreach]

wow awesome conversation! Answered all of my questions! Thanks
everybody!

> > > > > ∞ Google me:http://www.google.com/search?q=andrew%20badera-Hide quoted text -

[ElPlatero]

> Interesting tho, Twitter is putting a lot of trust in the third-party
> app that they won't mismange tokens. At least it's better than basic
> auth. Thanks again.

I don't think so. It's the _user_ who's asked if he trusts that third
party app to not mismanage tokens. Twitter's got nothing to do with
it, if you think about it.

Tino