On 4/16/09 12:55 PM, Doug Williams wrote:
Related: More OAuth documentation is to come throughout the day so
some of the links will be broken. It's a glaring omission in the
documentation.
Let's use this thread to fill the holes people find while implementing
Sign in with Twitter for the time being.
One issue I have is that the oauth/authenticate method expects an
oauth_token as part of the request. Until we've authenticated the user,
how do we _know_ what the user's oauth_token should be?
Are we supposed to request and use a new unauthorized token every time
we present the "sign in with Twitter" button in our third-party
application? (You can smell why this idea stinks, right?)
Also, the redirect to the callback URL has no signature. What stops an
attacker from brute-force attacking an OAuth consumer, iterating through
posisble tokens? Simply the large search space of valid OAuth tokens?
Even if it's only "possible in theory" ... some teenager with nothing
better to do is going to eventually turn that theory into practice.
What would be ideal is a method that we can link a user to that follows
the oauth/authenticate 4-step decision tree described on the wiki but
requires only a callback URL. When Twitter sends the user back via the
callback URL, it should include a valid OAuth access token, Twitter user
ID and screen name, and signature.
Then, another method like oauth/token where a signed request with the
OAuth token can be made that returns the token secret.
Possible?
--
Dossy Shiobara | [email protected] | 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)
