OAuth Authentication - clarification needed

[djMax]

Ok, I've dug into some basics of OAuth and also the code of Tweet#.
After authorization, I'm armed with my user record and a map of it to
an OAuth token (A) and secret (T1). Now, weeks later, the user
returns to my site with no cookies (let's say). So I show them the
Twitter signin button. They click it. My server calls RequestToken
from Twitter and gets a token (and a secret?). It sends them to
Twitter, they login, and then Twitter redirects to me with a OAuth
Token (A) on the URL.

That's where I'm confused:what do I do next? If I try to turn that
OAuth Token into an access token, it fails, assumedly because it
already is an auth token. But I must have to contact Twitter somehow
to verify that the oauth token the browser passed me is still good
right?

[Dimebrain]

Assuming that the authentication process is handing you off the actual
access token, it makes sense that it can't be exchanged. I don't think
the token will expire on you though, at least today, so you don't
really need any more verification other than maybe running account/
verify_credentials against it.

It should be no different than if you persisted the access token
yourself and went to call the API a few weeks after doing so, you
should be able to trust that your token won't expire.

[djMax]

If this is true, this is broken from a security perspective, IMHO.
Basically it says that if anyone guesses an oauth_token, they can
login to any site without having any idea who the user that maps to
that token is.

[Dossy Shiobara]

On 4/16/09 9:46 PM, djMax wrote:
> That's where I'm confused:what do I do next? If I try to turn that
> OAuth Token into an access token, it fails, assumedly because it
> already is an auth token.

Right, the oauth/authenticate returns the user to your callback URL with
an AccessToken, not the original RequestToken you sent to
oauth/authenticate. How is the OAuth consumer supposed to know the
token secret for this returned AccessToken?

That's the problem I'm having, too, which is why I'm still using
oauth/authorize instead of oauth/authenticate.

--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[Dossy Shiobara]

On 4/16/09 10:56 PM, Dimebrain wrote:
> It should be no different than if you persisted the access token
> yourself and went to call the API a few weeks after doing so, you
> should be able to trust that your token won't expire.

But this still leaves the question of "how do I get and/or know the
token secret for the returned AccessToken" ... this is the current
execution path:

Consumer invokes oauth/request and receives a RequestToken and
corresponding token secret. Consumer directs user to oauth/authenticate
with RequestToken. Assuming user authenticates and authorizes the
application, Provider directs user back to callback URL with an
AccessToken. Consumer now has a RequestToken and secret, and
AccessToken without its secret.

That AccessToken is effectively useless to the Consumer.

[Dimebrain]

I think the thinking is, the first time a user authenticates using our
app, we get the access token and it's up to us to persist the secret.
Then we can use the authenticate approach, get back the user's token
(it should be the same one we have), and then match it up to the
access token paired to it.

So, yeah I think this makes the scenario where you want a simple app
that uses cookies not plausible for the authenticate scheme. You're
better off running authorize each time for those, or at most, just
when you no longer have the secret in hand.

So Twitter as auth provider, not quite.

[djMax]

This thread is kind of a dupe of

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a27298269b429a15

I'd suggest we move the convo over there? My last post in that thread
describes why I think the current flow is not secure, which is
essentially what Dossy says I think. That last token passed from
Twitter to the app cannot simply be the original permanent token.