This is down to good practice at the consumer end, The consumer shouldn't link a request token to a specific user until they receive the callback, at which point the request token should be looked up from the "bucket" of active request tokens based on the oauth_token value sent with the callback. The verification code then just ensures that the same person is requesting the access token as the person who requested the request token (as the callback is controlled during the request token step.) if the three steps are A: Request Token B: User Authorisation C: Access Token Swap. then the Callback links A:C and the verification code links B:C which means A:B:C are all linked suitably. there was no validation of this in the original spec which is why someone could hijack the process.
Is that correct? O 2009/5/9 Brian Eaton <[email protected]> > > On Fri, May 8, 2009 at 5:31 PM, Manish Pandit <[email protected]> > wrote: > > However, when it comes to web based > > consumers with callbacks, even with the oauth_verifier, the process > > ends up linking the good guy with the bad guy's request token at the > > provider. > > Sweet. Last time somebody said this it was late on a Friday, too, and > look how well that turned out. =) > > I'm pretty sure OAuth 1.0a isn't vulnerable to what you're describing, > but I can't explain why without a more detailed explanation of how > your attack works. Can you break it down into a step-by-step "evil > user does X, good guy does Y" flow? > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
