Ben Ward

The OpenID and OAuth Flow: Playing with UX

. Updated: .

Delegated authentication and authorisation technologies are one of the biggest developments of last year. Whilst still immature, technologies like OpenID and OAuth have their feet down as being integral pieces in the interaction between web services.

OpenID and OAuth are the open, standards based and interoperable editions of this technology, but Yahoo’s deprecated BBAuth and FlickrAuth and others all came before. Also at the tail-end of last year came Facebook Connect, a system whereby websites can piggyback on Facebook profiles for building applications.

For example, take Fire Eagle. It’s a service that stores your location on your behalf, for use by other applications on the web. It uses OAuth to control access to that location; no application can see your location by default. When you visit a site needing your location, it asks Fire Eagle for that information.

Instead providing your Yahoo! username and password to this third party site (which would grant access to your entire Yahoo! account), you are taken to a special page on the Fire Eagle site, click a button to grant specific location permission and then jump back to the original site, which now holds a token to access to your location.

OAuth Best Practices · Fire Eagle. Image by Ben Ward & Sam Tripodi

This process means that the site you shared your location with can’t access anything apart from your location (it can’t log into your Yahoo! IM account, for example, or send emails through Yahoo mail). Furthermore, you can log in to Fire Eagle and remove that application any time; you don’t need to change your password to do so.

It’s the future, it’s user empowering, and it’s going to be great. Eventually.

The user experience of this OAuth process — and OpenID alike — has been criticised a bit. Users don’t expect to be moved between different websites, but they are familiar with entering their passwords all over the place. The short ranty version of this article would go like this: If you stop whining and just get on with implementing the OAuth flow, users will get used to it and will be just fine. It’s is usable as-is, so shut up already. But this is the long, constructive version, so:

The user experience of OAuth and OpenID is immature, and can still be massively improved and smoothed out with concerted design effort.

Which brings me to Facebook Connect. Connect is a product as well as a proprietary technology. It’s a packaged and complete offering from Facebook, and as such, comes with a far more complete and polished user experience than the technology-focused, open standards have so far achieved. Polished and mind bogglingly stupid, in places, but, y’know.

Facebook Connect, whilst proprietary and product-specific and therefore irrelevant in the grand scheme of things, has UX that can be applied to OAuth and OpenID flows. If service providers support this, I think user experience gets much better, quickly.

How does Facebook Connect work?

The most common use case for Facebook Connect appears to be commenting on blogs, such as on Gawker sites. Rather than enter your details standalone, or uniquely register with a site, you log into Facebook, and Gawker uses those details instead.

So, you click the shiny ‘Facebook Connect’ button in the comments form, and an overlay appears:

A dialog confirmed your already logged in Facebook name, a button to confirm the ‘Connection’ and another to reject it.

This is the crux of the learning for OAuth. Rather than redirect to Facebook, this granting of permission happens right in the page in an embedded control.

It’s not quite as simple as this, mind. It’s ok that this action occurs in an overlay only because the user is already logged in to Facebook. No exchange of credentials takes place: The overlay is an iframe serving a page from Facebook’s server, so my current login cookie is used and there’s no need for Facebook to ask for my password. A malicious site would gain nothing by spoofing this dialog.

Since writing this article, Facebook have improved the behaviour of Connect. Now, if you are signed in you see an overlay as before, but if not signed in Connect opens a new window, where all usual browser functionality is available. This a huge improvement and fixes the complaints that follow.

Unfortunately, Facebook Connect then screws up. The whole point of delegated auth is that we stop users entering their passwords into third party sites. It has to stop. That means both actually entering their details into third parties, but also interface that gives the impression of giving your password to a third party. When you are not currently logged into Facebook, you instead see this dialog:

A Facebook dialog within the Gawker page, prompting for a Facebook username and password.

Millions of Facebook users, openly encouraged to enter their password into any site that asks. This is wrong. If the user is not already logged into the service, you should be redirected in a more traditional bounce between pages. That way browser-level phishing tools kick in, the URL in the address bar can be manually inspected by the user and, critically, the user is conscious of logging into a different service.

Facebook ranting aside, the first half of their Connect overlay UI would be very useful to enhance the user experience of OAuth and OpenID.

Here’s a hypothetical Fire Eagle app built into Last.FM.

A simple dialog prompting for your current location, ‘San Francisco’, and a button to invoke Fire Eagle as a source for that location.

In the current implementation of OAuth, clicking ‘Get Fire Eagle Location’ would redirect you to the Fire Eagle website, and then you’d redirect back again after clicking ‘Confirm’.

Instead, OAuth apps should do this by default:

Display the ‘Grant Permission to the Last.FM application’ UI in the page.

No redirect, lighter weight UI and more responsive feedback. This, I think, is something that OAuth APIs should support out of box along with their other language wrappers; provide drop-in support.

Now, this behaviour applies for logged in users only. If you’re not logged in to Fire Eagle for any reason, you should still be moved to the separate site as before. We need to stay strict on keeping users spatially aware of where they are entering their passwords, otherwise the whole effort is undermined.

Overlaid OpenID

With one example down, here’s a mock of how Open ID could benefit from the same integrated flow, this time working with Dopplr, since they already support Open ID:

A simple Yahoo! dialog overlaying the Dopplr website, asking the user to confirm they wish to log in. The surrounding UI for the current Yahoo! Open ID page is retained in this example.

If not logged in to Yahoo, you get a prompt and just as before, are guided to step through the regular, separate-site process to sign in:

The same Yahoo! dialog is overlayed on Dopplr, but this time telling the user they are not logged in, and need to sign in to Yahoo! before they can sign in to Dopplr.

Clicking ‘Sign in to Yahoo!’ would take the user to Yahoo’s standalone page.

How to make this happen?

For this to happen, services need to provide support for it; it can’t be done just at the client side. The dialog-sized interfaces for authorising applications or logging into sites need to provided, and they need to support the ‘break out to enter passwords’ flow. But, sites like Fire Eagle already provide a mobile-scale version of the auth page, so further variants are not a major hindrance.

It also needs a JavaScript component to handle the UI side. With a bit of luck, this only needs to be done once and shared between projects.

The core technology behind OAuth and OpenID is pretty robust. Both have major adopters like Yahoo and Google. OpenID has a bit of a bit of a way to go before users need it, perhaps, but regardless, it’s well into the same phase where user experience needs to be a concerted effort, and the status quo needs to be challenged.

Everything in this post is just a small step from what we already have, it’s just smoothing out the edges. Maybe that’s enough, but I suspect there’s a long way to go and a wealth of other ideas out there.

Comments

Previously, I hosted responses and commentary from readers directly on this site, but have decided not to any more. All previous comments and pingbacks are included here, but to post further responses, please refer me to a post on your own blog or other network. See instructions and recommendations of ways to do this.

  1. These are some vey sound ideas on improving the user flow and weeding out bad practices. Thanks dr paying it out so clearly.

    “Stop logging me out each time I blink, please.”
    Amen. Drives me crazy!

    Cheers Ben.

  2. Ben,

    Wonderful read. I almost stopped at the short version, but the lengthy one is far juicier. :)

    I really like the UX mockup you came up with, but I’m concerned. In the case of OpenID, you’re ignoring the “authorize this app forever” option and also far more complex operations in terms of UI like SimpleRegistration and AttributeExchange. Do you propose this should be done on the RP/consumer or should you be presented with a “You need to jump to our website to choose which data should be revealed to this app”…?

    Your thoughts?

  3. 1 – I am worried that your light box, with no way to see the URL, is open to malice and deception. One of the most reassuring parts of proper Oauth delegation, for me at least, is being taken to the external site and seeing the correct URL in the address bar. How hard could it be to make a fake light box?

    2 – I was going to type “Facebook FAIL” but its such a perpetual occurrence, all the fun of doing so is gone now.

  4. Wondering if, given a standard UI widget, something like BofA’s site key (http://en.wikipedia.org/wiki/Sitekey) would provide enough assurance to enter credentials in non-logged in case to avoid full trip to OP site …

  5. Just to correct a misperception, with Facebook Connect we do use a popup when asking for user credentials. The Javascript checks if the user is logged in, and if so then uses the lightbox. I think you found a corner case where you were logged into Facebook when you loaded the page, but then logged out before Connect was completed (perhaps by clicking “Not you?” link).

    I’m really excited by the prospect of bringing the ideas from Connect into the OpenID/ Oauth flows around the web. There’s no technical reason why the user experience can’t be fantastic with the open standards, and I’m keen on working to make that a reality.

    For example, one addition to the OpenID spec that would help here is if an OP could optionally return an additional failure code, which said basically “the user is logged in, but has not authorized your website”. The RP could then choose to display the auth dialog in an iframe, knowing that the user won’t be asked to enter their credentials. The OP can then break out of an iframe if it actually needs credentials, thus keeping the user safe.

  6. Ben

    André: In the case of the OpenID mockup I was simply translating the current Yahoo OpenID UI into an overlay. As underlies this whole concept, so long as you are already signed into your OpenID provider (and thus, do not need to enter any credentials to a third party site), any of the more complex information exchange extensions could take place.

    Todd: The overlay ‘lightbox’ UI would only be for users who are already signed into the service provider. So, if you use a Fire Eagle app but are not yet signed into Fire Eagle (or if your cookie has timed out), then you would move over to a separate, verifiable page as per normal. The overlays are designed so that no-one, ever, ever enters their password into a third party site.

    Now, yes, it would be trivially easy to clone an overlay like these, but the only UI allowed in the overlay is what happens after you’re already logged in. No user ever enters a username or password into this UI, so cloning them as-is has no value, you can’t gain any real information from them.

    This is where the Facebook UI crashes into a fiery wreck, since you can clone their UI precisely and genuinely, and still obtain passwords. This OAuth/OpenID version, where passwords are only entered back at the service itself, those services could make a bigger deal of educating their users to be vigilant. ‘Only enter you password on this page, never on someone else’s website.’

  7. Oh, here’s some of the info we shared about the Facebook Connect UX from when we presented on it in November: http://therealmccrea.com/2008/10/20/live-blogging-the-openidoauth-ux-summit/

    Also, just to introduce myself, I am an engineer working on Facebook Connect.

  8. Hi Ben

    Good article. I’m writing a short piece for .Net, not about OAuth (I’d be far from qualified to write about that, though I do mention it) but just about why asking for third party passwords is a bad idea, and this is all useful stuff.

    One point though – it seems that Facebook Connect does open in a new window with address bar when asking for username/password. Even then this is not infallible, as would non-geeks notice if it’s in an iFrame? Or in a chromeless window that emulated the address bar? Someone will always find a way round it.

  9. Ben

    Paul,

    It seems that since I wrote this article Facebook have improved their behaviour. (They’re a bright bunch, really).

    What now happens is that if you are not already logged in, a new window opens. If you are are logged in, you get the lightbox style overlay.

    It is possible to get a password prompt in the page if you are already logged in but click the ‘I’m not Ben Ward’ link to log in as a different user. That should probably invoke the separate window as well, but for most of their use, they’ve nailed it.

    As to whether you can clone this new interface successfully. I guess. But browser chrome is harder to clone accurately (and cross platform). Some research into how aware users are is important, really. We need to start educating them on log-in pages, I think.

You can file issues or provide corrections: View Source on Github. Contributor credits.