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.

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.

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

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.’

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.

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

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?

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

Cheers Ben.