FYI - many OAuth implementations, including ours at LinkedIn, use frame-busting javascript to insure that the authorization form is not iframed. The LinkedIn terms of service (and many others) also stipulate that the URL bar must be visible and the authorization form must not be iframed.
On Mon, Jan 18, 2010 at 12:53 PM, John Panzer <jpan...@google.com> wrote: > 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 <p...@eval.ca> 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 <p...@eval.ca> 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: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On > Behalf Of Paul Osman > >>>> Sent: Sunday, January 17, 2010 5:12 PM > >>>> To: oauth@googlegroups.com > >>>> 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 oa...@googlegroups.com. > >> To unsubscribe from this group, send email to > oauth+unsubscr...@googlegroups.com <oauth%2bunsubscr...@googlegroups.com>. > >> For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > >> > >> > > > > > > -- > -- > John Panzer / Google > jpan...@google.com / 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 oa...@googlegroups.com. > To unsubscribe from this group, send email to > oauth+unsubscr...@googlegroups.com <oauth%2bunsubscr...@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > > > >--
You received this message because you are subscribed to the Google Groups "OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
