It just dawned on me: it looks like /oauth/authenticate is designed to merely deliver a user's ID and screen_name to a application, not to authorize the application to access Twitter on the user's behalf. Is that so?
A suggestion: treat the user ID and screen_name as a resource that's protected by OAuth. Define /oauth/authenticate as the place a user authorizes an application to get the ID and screen_name. So, the flow would go like this: 1. The application GETs a request token from /oauth/request_token. 2. The application redirects the user's browser to /oauth/ authenticate. 3. The user authenticates and/or gives permission, if needed. 4. Twitter redirects the browser to the application callback. 5. The application GETs an access token from /oauth/access_token. 6. The application GETs the user ID and screen name from /account/ verify_credentials or something similar. No sensitive data are passed from Twitter via browser redirects to the application. The application may use HTTPS to secure its requests to twitter.com/oauth. On Apr 16, 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.
