Why an OAuth iframe is a Great Idea

Picture 1At SetJam we use OAuth to link to your Netflix account.  To simplify this process for the user, our head of UI suggested we just frame the whole OAuth experience and present it as a light box that swaps out the various elements as someone authenticates.  For those of you who understand what the above means, you can probably imagine this caused a bit of discussion in the office.  For those of you who think the above is a bunch of gobbledygook, let me explain, since this post is for you.

OAuth is a specification that allows a site like SetJam to manage resources for you on another site (in this case, Netflix).  In order for us to be able to do this, Netflix needs to know that you trust SetJam.  The cool thing about OAuth is that it allows you to tell Netflix that you trust SetJam WITHOUT having to give us your Netflix username and password.

This is good for you because if you decide you don’t want to use SetJam to manage your Netflix queue anymore (as preposterous as that sounds!), you can just tell Netflix and we have no personal information about you.  This is good for SetJam too because we have no personal information (and thus nothing that can get stolen).

In order to establish this trusted relationship, you need to tell Netflix that you trust SetJam, and here’s where the issue begins.  One way to do this is for SetJam to pop open a brand new browser window and take you to Netflix where you can enter your username and password.  Once you do, Netflix will confirm that the relationship has been established and direct you back to SetJam.

The above SOUNDS simple but it really doesn’t FEEL simple.  No matter how we implement this, your browser settings will mess it up.  The new window will pop up in a new tab for some, for others the new window will get lost, and when (if) you return, many of you will have your Setjam window automatically resized to an unusable dimension.  We can do things to minimize this, but you’ll feel a little disoriented.  I might even say deceived.

To prevent this, we can technically contain this entire experience in a simple dialog that hovers over your SetJam (which is where you started and really want to be).  The dialog pops up, you agree, it goes away.  No harm done right?

Well, technically there is a problem.  How do you KNOW that the little dialog that popped up was really from Netflix and not an evil attempt by SetJam to STEAL your Netflix credentials?  The answer is you don’t.  The reason the OAuth community prefers that we open up a new window is that if you look at the URL in the window (the place you type in a site’s name), you would see that it says www.netflix.com* and know that you are giving your credentials to Netflix.

Or would you?  I would!  Other technologists would!  But would you?  Would you even notice?  If you noticed would you care?  The answer for the VAST majority of the world is of course, no.  In fact to an average person, getting taken to an ENTIRELY other site with some weird little dialog floating in a big page is EXTREMELY suspicious.  The real site you are trusting to do the right thing is SetJam (not weird pop-up window site).

The real problem is with OAuth itself.  The OAuth community made a compromise—lighter security for lighter implementation.  This was a VERY good decision, as it allows small companies like SetJam to do amazing things.  The problem is when technologists, in an ill-fated attempt to promote OAuth as a truly secure technology, make it unusable.

I’m sympathetic with the community’s position.  They don’t want people to get used to framed implementations from trusted sites like SetJam, because then it will feel natural when a malicious site does the same thing for the wrong reasons.  The community, however, is deluding itself if it thinks that having an exposed URL is going to do anything to prevent this.

My belief is that OAuth consumers have a choice:  Create a confusing, suspicious feeling, and entirely phishable OAuth implementation OR create a simple, seamless, and entirely phishable OAuth implementation.  For the sake of the emerging seamless web toward which everyone in the OAuth community is working, I think the choice is clear.

  • dss

    Why wouldn't you use the "oauth_callback URL" so that the Netflix login page replaces the SetJam page temporarily (without forcing a new pop-up window) thus complying with the community's "open URL" standard?

    (As outlined in this state diagram: http://sitepen.com/labs/code/ttrenka/oauth/oauth-

    • http://intensedebate.com/people/drstarcat drstarcat

      Eh… We could, but I feel like the full redirect is even worse than
      popping up another window. If the claim holder sites didn't make
      their authentication pages so ugly it wouldn't be so bad, but
      typically they're just a login box surrounded by a black background!

      rj

      Sent from my iPhone

  • mk

    Regular user will trust you and enter the netflix credentials into the iframe/dialog. We (paranoid techies) are the only ones that will start a debate whether this is a good idea or not.

    Your biggest problem will probably be technical: since the iFrame sends requests to a third party SSL server from your (presumably) non-secure site, you will have absolutely no access to anything happening inside of that page.

  • simonwillison

    Please, please don't do this.

    As web developers we have a shared responsibility to help our users stay safe on the internet. This is becoming ever more important as people move more of their lives online.

    It's an almost sisyphean task. If you want to avoid online fraud, you need to understand an enormous stack of technologies: browsers, web pages, links, URLs, DNS, SSL, certificates… I know user education is never the right answer, but in the case of the Web I honestly can't see any other route.

    The last thing we need is developers making the problem worse by encouraging unsafe behaviour. That was the whole POINT of OAuth – the password anti-pattern was showing up everywhere, and was causing very real problems. OAuth provides an alternative, but we still have a long way to go convincing users not to hand their password over to any site that asks for it. Still, it's a small victory in a much bigger war.

    If developers start showing OAuth in an iframe, that victory was for nothing – we may as well not have bothered. OAuth isn't just a protocol, it's an ambitious attempt to help users understand the importance of protecting their credentials, and the fact that different sites should be granted different permissions with regards to accessing their stuff. This is a difficult but critical lesson for users to learn. The only real hope is if OAuth, implemented correctly, spreads far enough around the Web that people start to understand it and get a feel for how it is meant to work.

    By implementing OAuth in an iframe you are completely undermining this effort – and in doing so you're contributing to a tragedy of the commons where selfish behaviour on the behalf of a few causes problems for everyone else. Even worse, if the usability DOES prove to be better (which wouldn't be surprising) you'll be actively encouraging people to implement OAuth in an insecure way – your competitors will hardly want to keep doing things the secure way if you are getting higher conversion rates than they are.

    So once again, please don't do this.

  • http://intensedebate.com/people/simonwillison simonwillison

    Posted a bit more about this here: http://simonwillison.net/2009/Jul/16/responsibili… – including a call for OAuth providers to add frame-busting JavaScript to their authorisation pages.

  • Gryffyn

    It’d be great if oauth style authentication could be built into the browser itself so the browser could display a box showing the URL, security certificate, etc along with the username/password prompt for the site. Then you have your “popup window” without worries of tabs/popup blockers/etc and offering some assurance that you’re logging into the correct place.

  • Pingback: Teaching users to be secure is a shared responsibility | dv8-designs

  • Richard Lynch

    Give users the popup pretty one, and provide a link for the paranoid.

  • http://intensedebate.com/people/drstarcat drstarcat

    Btw… because of your suggestion, we're going to do the following:

    You need to let Netflix know that you want to use SetJam:

    If you've already got a Netflix account <login here>.

    If you don't have a Netflix account, <start your 30 day free trial here>.

    [smaller] We won't store your Netflix login information, if you'd prefer to enter your login information at Netflix, click here.

  • http://developer.netflix.com jr conlin

    Actually, uhm, no.

    Users should trust no one. That includes both the SetJam and the Netflix login page.

    Users should never, ever give out their credentials to any page that is not one they recognize and can provide some level of due diligence to. It's terribly simple to create a mock-up of the Netflix login page, acquire someone's credentials and cause all sorts of havoc. The sore weakness in OAuth is the fact that users must remember to check the URL of the page being displayed. Until such a time as there is a non-spoofable mechanism to provide a visual indication of the validity of the login site, the URL is really the only option.

    By the way, we have frame busting code in our login page so your approach shouldn't work. Let us know if it does and we'll fix the bug.

  • hans

    "This is good for SetJam too because we have no personal information (and thus nothing that can get stolen)."

    But, you have the token + secret, and anyone that has a copy of those will be able to perform all the operations you can. (OAuth doesn't mandate that tokens are tied to an identity.)

    • http://robimy.net/ Ryszard Szopa

      Well, there's nothing we can do about it: this danger is intrinsic to OAuth (and, let's face it, any authorization system). On the bright side, the user can always deauthorize the token on the provider's site if he suspects something fishy is going on.

  • http://intensedebate.com/people/simonwillison simonwillison

    You're right that redirects alone aren't the answer – OpenID has suffered from this same phishing problem for years, any time you have an untrusted site that's meant to redirect you to a trusted one there's potential for trouble.

    In the long-run, the solution lies with the browsers. My browser should understand OAuth (and OpenID) and provide un-spoofable chrome confirming that I'm on the correct site.

    That's another argument for sticking with the redirect though – if sites are using the redirect, browsers can start adding their own level of protection and it will Just Work with existing OAuth deployments.

    • http://drstarcat.com Ryan Janssen

      That last point about backwards compatibility is an interesting one Simon. I agree that whatever we end up with will be part of browser (Google OS?), though, in reality, the odds of it being backward compatible are pretty remote.

  • Parsingphase

    I'm sorry, but this is raging lunacy. You want to teach people to type their password on one site into any arbitrary other site? How many "regular users" even know what an iframe is anyway? What about sites with ads – should we tempt users to type their passwords into random advertisements?

    This is not a weakness of Oauth; it goes deeper, into the structure of the web and the browser. But you're not going to make it better this way.

    Seriously, teach a man to get phished and you'll **** him up for life.

  • Torgeir

    I don't understand why you all fear URLs so much.

    More and more browsers are adding security indications to the URL bar, and teaching user to pay attention to it is already a good idea.

    Easy isn't always good, and as Parsingphase points out; this iframe float will only teach users to trust "check if your computer is infected" adds.

  • Pingback: Who is Hahleq? : Items I found interesting on July 15th through July 22nd

  • simonwillison

    Please, please don't do this.

    As web developers we have a shared responsibility to help our users stay safe on the internet. This is becoming ever more important as people move more of their lives online.

    It's an almost sisyphean task. If you want to avoid online fraud, you need to understand an enormous stack of technologies: browsers, web pages, links, URLs, DNS, SSL, certificates… I know user education is never the right answer, but in the case of the Web I honestly can't see any other route.

    The last thing we need is developers making the problem worse by encouraging unsafe behaviour. That was the whole POINT of OAuth – the password anti-pattern was showing up everywhere, and was causing very real problems. OAuth provides an alternative, but we still have a long way to go convincing users not to hand their password over to any site that asks for it. Still, it's a small victory in a much bigger war.

    If developers start showing OAuth in an iframe, that victory was for nothing – we may as well not have bothered. OAuth isn't just a protocol, it's an ambitious attempt to help users understand the importance of protecting their credentials, and the fact that different sites should be granted different permissions with regards to accessing their stuff. This is a difficult but critical lesson for users to learn. The only real hope is if OAuth, implemented correctly, spreads far enough around the Web that people start to understand it and get a feel for how it is meant to work.

    By implementing OAuth in an iframe you are completely undermining this effort – and in doing so you're contributing to a tragedy of the commons where selfish behaviour on the behalf of a few causes problems for everyone else. Even worse, if the usability DOES prove to be better (which wouldn't be surprising) you'll be actively encouraging people to implement OAuth in an insecure way – your competitors will hardly want to keep doing things the secure way if you are getting higher conversion rates than they are.

    So once again, please don't do this.

  • air max shoes

    I totally agree the standpoint of upstairs, and I believe this will be a trend. I often come this forum , rom here I learn much and know the newest tide! the content here constantly update and I love it! Another I know some websites which often update their contents, you guys should browse if into321 you are free.

  • http://www.usa-basketball-shoes.com basketball shoes

    Here elaborates the cake-like.com matter not only extensively but also detailly .I support the write's cake-like.com unique point.It is useful and benefit to your daily life.You can cake-like.com go those sits to know more relate things.They are strongly recommended by friends.Personally

  • http://audiodecoders.blogspot.com audio codecs

    Yep. I agree with you

    Just so you know, there's frame-busting code in the login page to prevent that sort of thing anyway.

  • findingdream123

    In the 1960s, some Latin American countries [url= http://www.findingdream.com/wh...]wholesale hair
    weave[/url]
    In the 1960s, some Latin American countries [url= http://www.findingdream.com/wh...]wholesale hair
    weave[/url]

  • findingdream123

    In the 1960s, some Latin American countries tried to solve this problem
    by setting up special “return” programs to encourage their
    professionals to come back home. [url= http://www.findingdream.com/wh...]wholesale hair
    weave[/url]In the 1960s, some Latin American countries tried to solve this problem
    by setting up special “return” programs to encourage their
    professionals to come back home. [url= http://www.findingdream.com/wh...]wholesale hair
    weave[/url]

  • Pingback: short order promotion codes

  • Pingback: fifa 15 téLécharger

  • Pingback: the sims 4 télécharger

  • Pingback: cruisecompete.com review

  • Pingback: steroid storonto

  • Pingback: buy steroids mississauga

  • Pingback: helpful site

  • Pingback: teeth whitening kits uk

  • Pingback: gift etc

  • Pingback: math-Preview.wmflabs.org

  • Pingback: otterbox defender iphone 5

  • Pingback: More methods

  • Pingback: Emulator nintendo 3ds

  • Pingback: Gbaforios.over-Blog.com

  • Pingback: Suggested Studying