At the risk of being yelled at, I wanted to get something cleared up. So I am in the process of updating my provider and going through the draft-2. However, I fail to understand (still!) how it fixes the original problem in case of callbacks. Desktops and no callback situations, I get it perfectly. 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. I am going to upgrade my impl to keep the tokens one time use only, callback_url signing and oauth_verifier fix. However, the protection does not add up, as the attacker is behind the consumer, and the consumer is the one who automatically gets an access token upon receiving the callback with the verifier attached to it. This in turn still ends up linking the wrong identities on the provider. I know the TTL for request token and one-time access kind of mitigate the problem, but somehow I fail to understand how this actually fixes it..
*runs for cover* -cheers, Manish --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
