Zac, Matt and I agree there is value here. I've opened Issue 469 [1] to track this enhancement.
1. http://code.google.com/p/twitter-api/issues/detail?id=469 Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 16, 2009 at 11:48 AM, Dossy Shiobara <[email protected]> wrote: > > On 4/16/09 2:33 PM, Matt Sanford wrote: > >> The initial token required is a RequestToken rather than an AccessToken. >> Making the request for the RequestToken requires you know the consumer >> key/secret and (a) let's us know what application this is for >> (callback_url alone would not) and (b) prevent the token-shooting method >> you described. >> > > How does this prevent (b)? If I know a third-party application's callback > URL, I can currently brute-force a user's oauth_token, assisted by a basic > session-fixation attack. The callback URL isn't signed by Twitter. > > Perhaps oauth/authenticate would require a signed request that doesn't > include/require oauth_token. Upon successful process flow, Twitter would > send the user back using a signed callback URL that includes the user's > oauth_token. Then, all we would need is a method to retrieve the > oauth_token_secret for that oauth_token. > > This would enable third-party applications to completely use Twitter for > its authentication, in lieu of OpenID. > > > > -- > 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) >
