first of all, my sincere thanks to all those involved in this for how it has been managed!
Since reading the advisory and the post an Eran's blog, I kept ruminating about the issue, here are a few thoughts: To solve the problem we'd need a way to make it impossible (or at least very hard) for the attacker to get an access token from the request token authorized by the real service provider user. Since the attacker knows the request token (he has generated it) we need some information to be passed around that the service might use to verify that the request token is being exchanged with the access token by the same user that authorized it. It could be some token (or signature) that the service provider generates before sending the user back to the consumer to complete the request and that should be passed to the service provider upon token exchange. I guess that this is more or less what Eran said in the blog: "an unpredictable callback parameter generated at the Service Provider to the callback URI on return". But if we do so we also need to make sure that the callback URL is NOT taken from the parameters passed in the redirect to the service provider that the user follows when authorizing (step 6.2.1 of the spec) or at least that it is "vetted" (allowing only those within a specific domain). If the Service provider accepts any redirect then any information that it want to pass back to the consumer might be intercepted by the attacker (via a callback that goes through an attacker controller host). Another option to make sure the SP can pass information to the consumer would be to add the oauth_callback parameter to the request token request (step 6.1.1) and use that callback when the request token is exchanged for the access token (this parameter should be generated by the consumer site and not know to the user or the attacker until the redirect). A last thing that might mitigate social engineering attacks could be to require the consumer to pass to the service provider some information about who their user who is requesting the request token is, then the service provider could show this infos to the user trying to authorize the request token (e.g. the SP may say: "you are going to authorize the user Xyz at the service Abc access to your data"). what do you think? ...just my 2c Luca --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
