On Thu, Apr 23, 2009 at 6:16 PM, Dossy Shiobara <[email protected]> wrote: > I won't go into those details until a reasonable fix is available. :-)
The details are on Eran's blog. >> 1) Keep using OAuth 1.0. >> SPs can tell users that they are authorizing an application on >> their desktop. There is some risk of social engineering as you >> describe, but hopefully the language on service provider pages >> mentioning desktop applications will help. > > The problem here is that attackers can leverage other vulnerabilities > (in browsers, in provider implementations, etc.) to make the victim's > active participation entirely unnecessary. Browser bugs: browser bugs are game over for almost everything. Provider implementation bugs: we should provide better documentation of what service providers need to get right to prevent these attacks. I think this is an area we should work very hard to get right in the revised specification. > Not sure about the language of "callback token" here, which to me > implies something that happens during or after the process is complete. > What we need is an "identity token" - something that an authenticated > user requests from the Provider and feeds it into the Consumer which it > can use to begin the request+authorization flow. A flow like this? 1) User visits SP, gets "identity token" 2) User enters "identity token" into desktop app. 3) Desktop app sends user back to SP again. 4) User approves access at SP. 5) User goes back to desktop to approve access. That's not a good user experience, nor is it necessary to fix the security problems in the protocol. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
