Perhaps: If the browser sees an unknown SP in an iframe, it instead shows a warning with a link to pop open in a full window. But it looks like an iframe to the host page js still, and removes itself at the right time in the flow - turning back into an iframe after the user enters a password and sends it to the server.
On Monday, January 18, 2010, Paul Osman <[email protected]> wrote: > I completely agree that checking URLs isn't the best possible defence, > because, as you mention, how many users actually check the url? > Unfortunately, at the moment, it's the only thing that is effective 100% of > the time. I think it's better than it was... awareness about phishing scams > and malware sites is slowly training users to be more diligent in this regard. > > I love the idea of browsers issuing warnings if a user is visiting, for the > first time, a site claiming to be an OAuth SP. I think browsers could do a > lot in this regard and it'd be a huge sign of success for this community to > see them take this kind of thing up. Maybe support for maintaining a > whitelist of OAuth SPs that the user has accounts with. If the user is > redirected to a site they haven't whitelisted, the browser can present them > with a subtle warning asking if they're sure they want to give their > credentials to an unknown party (maybe the user knows what they're doing... > maybe they've recently cleared their browser data, etc). > > An obvious question is, how do we push browsers in this direction? What can > be done to encourage browsers to treat previously unseen OAuth SPs in a > similar way that invalid SSL certs are treated... or as you mention, bad-site > iframes. > > Cheers, > Paul > > On 2010-01-18, at 10:31 AM, John Panzer wrote: > >> Devils advocate: I know all of the arguments pro URL bar. Note that >> even without that, the browser will issue warnings if iframe'd over to >> a known-bad site. At least modern browsers will. I suspect those >> warnings are far more effective, when they trigger, than users >> checking urls. Perhaps browsers can do more - a subtle clue about >> phishing today is that your password field is not prefilled; could >> they be more blatant? Issue warnings for entirely new sites the user >> has never seen that claim to be OAuth SPs? >> >> How many users actually check urls? How many are equipped to check >> urls with Unicode characters? >> >> Would it be possible to get 99% of the security with an iframe plus a >> button to pop out to a full window to complete the action? The latter >> would be chosen by a self selected group of people who actually check >> urls and are potentially giving up a high value password. >> >> And, it'd be far more usable, letting more sites abandon the >> collect-the-password antipattern, leading to better security overall. >> >> On Monday, January 18, 2010, Paul Osman <[email protected]> wrote: >>> Hi Willem, >>> >>> While it's obviously not something that is covered in the spec (User-Agent >>> specific details are understandably out of scope), I would say that it is >>> strictly necessary. It gets into the "spirit" vs the "letter" of a >>> specification. In my view, using a browser and hiding the location bar >>> breaks the spirit of OAuth and makes the user authorization step less >>> secure. >>> >>> True, users can always view the location of the page through the >>> properties, but why introduce that hurdle? What percentage of users will >>> know to check that? >>> >>> As Chris mentioned in another reply to this thread, there are two pieces of >>> information that a user must have: >>> >>> * the URL where they're entering their password >>> * whether the connection is secure (ie using SSL) >>> >>> The best way to communicate this information in most browsers is the >>> location bar. >>> >>> Anything that obfuscates the source of the authorization screen, in my >>> opinion, breaks an OAuth implementation because it interferes with a users >>> ability to identify critical pieces of information (the URL and the >>> security details of the connection). >>> >>> Cheers, >>> Paul >>> >>> On 2010-01-18, at 5:13 AM, Willem Jan Gerritsen wrote: >>> >>>> Hi, >>>> >>>> A user can always view the location of a page through the properties. >>>> Being able to view the URL in the location bar is useful, but is it >>>> strictly necessary? >>>> >>>> Regards, >>>> Willem Jan >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>> Paul Osman >>>> Sent: Sunday, January 17, 2010 5:12 PM >>>> To: [email protected] >>>> Subject: Re: [oauth] Best Practice >>>> >>>> If the user cannot reliably see who is presenting the authorization-sign >>>> in window, they have no idea who they are giving their credentials to. >>>> This makes the whole point of delegated authorization moot, so I would >>>> consider it absolutely necessary to direct the user to a browser window >>>> where the location bar is visible. >>>> >>>> Cheers, >>>> Paul >>>> >>>> On 2010-01-17, at 10:17 AM, eco_bach wrote: >>>> >>>>> Hi >>>>> Building a Twitter application using OAuth. >>>>> I'd like to embed the Twitter OAuth authorization-sign in window >>>>> WITHIN my application. >>>>> >>>>> Is this considered a best practice, or is it always recommended to >>>>> send the user to a new browser window for the service provider(Twitter >>>>> in this case) authentication process? >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "OAuth" group. >>>>> To post to this group, send email to > -- >> 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. >> >> > > -- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer
-- 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.
