Facebook Usernames and OpenID
Today’s launch of Facebook Usernames provides an obvious and exciting opportunity for Facebook to become an OpenID provider. Facebook have clearly demonstrated their interest in becoming the key online identity for their users, and the new usernames feature is their acknowledgement that URL-based identities are an important component of that, no doubt driven in part by Twitter making usernames trendy again.
It’s interesting to consider Facebook’s history with regards to OpenID and single sign on in general. When I started publicly advocating for OpenID back in 2007, my primary worry was that someone would solve the SSO problem in a proprietary way, irreparably damaging the decentralised nature of the Web—just as Microsoft had attempted a few years earlier with Passport.
When Facebook Connect was announced a year ago it seemed like my worst fears had become realised. Facebook Connect’s user experience was a huge improvement over OpenID—with only one provider, the sign in UI could be reduced to a single button. Their use of a popup window for the sign in flow was inspired—various usability studies have since shown that users are much more likely to complete a SSO flow if they can see the site they are signing in to in a background window.
Thankfully, Facebook seem to understand that the industry isn’t willing to accept a single SSO provider, no matter how smooth their implementation. Mark Zuckerberg made reassuring noises about OpenID support at both FOWA 2008 and SxSW 2009, but things really stepped up earlier this year when Facebook joined the OpenID Foundation Board (accompanied by a substantial financial donation). Facebook’s board representative, Luke Shepherd, is an excellent addition and brings a refreshingly user-centric approach to OpenID. Luke was previously responsible for much of the work on Facebook Connect and has been advocating OpenID inside Facebook for a long time.
Facebook may not have committed to becoming a provider yet (at least not in public), but their decision to become a consumer first is another interesting data point. They may be trying to avoid the common criticism thrown at companies who provide but don’t consume—if they’re not willing to eat their own dog food, why should anyone else?
At any rate, their consumer implementation is fascinating. It’s live right now, even though there’s no OpenID login box anywhere to be seen on the site. Instead, Facebook take advantage of the little known checkid_immediate mode. Once you’ve associated your OpenID with your Facebook account (using the “Linked Accounts” section of the settings pane) Facebook sets a cookie remembering your OpenID provider, which persists even after you log out of Facebook. When you later visit the Facebook homepage, a checkid_immediate request is silently sent to your provider, logging you in automatically if you are already authenticated there.
While it’s great to see innovation with OpenID at such a large scale, I’m not at all convinced that they’ve got this right. The feature is virtually invisible to users (it took me a bunch of research to figure out how to use it) and not at all intuitive—if I’ve logged out of Facebook, how come visiting the home page logs me straight back in again? I guess this is why Luke is keen on exploring single sign out with OpenID. It sounds like the current OpenID consumer support is principally intended as a developer preview, and I’m looking forward to seeing how they change it based on ongoing user research.
As OpenID provider implementation is an obvious next step that can’t be that far off—I wouldn’t be surprised to hear an announcement within a month or two.
HTTP redirect codes
As an aside, I decided to check that Facebook were using the correct 3xx HTTP status code to redirect from my old profile page to my new one. I was horrified to discover that they are using a 200 code, followed by a chunk of JavaScript to implement the redirect! The situation for logged out users is better but still fundamentally flawed: if you enable your public search listing (using an option tucked away on www.facebook.com/privacy/?view=search) and curl -i your old profile URL you get a 302 Found, when the correct status code is clearly a 301 Moved Permanently.
One final note: it almost goes without saying, but one of the best things about OpenID is that you can register a real domain name that you can own, instead of just having another URL on Facebook.
Thank you for this and all the other articles, I enjoy them.
Sorry if I go off topic but I would like to have a clarification on your last sentence.
You say:
"one of the best things about OpenID is that you can register a real domain name that you can own, instead of just having another URL on Facebook."
this was in fact the selling point to me, I dont't have to trust a provider to stay online since I can mask it below my domain name, but my question is: is this behaviour enforced by openid? because it seems not so: for example on facebook I am not linked as matteoscotuzzi.com and myopenid is my linked account instead... in this case if myopenid shuts down its service facebook will not recognize matteoscotuzzi.com associated with another provider?
Thanks!
Thank you, your essay is both thoughtful and persuasive.
Aquarion - 13th June 2009 18:54 - #
What a timely essay. Well done.
A thought on redirects; the underlying Facebook vanity URI mechanism may have no reason to believe that this is a permanent redirect. The "you cannot change your vanity username" bit may be entirely a product choice, possibly decided late in the day.
If usernames can be changed, having FB keep track of all the old ones to get the infrastructure needed for 301 is considerable pain. In this case, 302 is acceptable (since it can be marked as cacheable, unlike 303).
@James Aylett I think that discussion is happening over at Mark Pilgrim's blog. Or hopefully it will be soon.
Sean McCullough - 13th June 2009 19:43 - #
Thanks for mentioning that I could register a real domain name that I can own, instead of just having another URL on Facebook.
Made _me_ laugh.
SlexAxton - 13th June 2009 19:46 - #
We have been using the popup style OpenID verification. Take a look at aswath.mocaedu.com
Wait, you can register a real domain name that you can own? The devil you say!
Apropos, if a declared OpenID 302-redirects to a www subdomain, I think the original entered OpenID should be the one used. We'll have to get @mnot on this right away.
Heh! How amusing that you fulfilled the prophesy on 30x and your essay: http://dashes.com/anil/2009/06/the-future-of-faceb ook-usernames.html
Are you sure about the JavaScript redirect? I'm seeing a 301 on the link to my page.
http://web-sniffer.net/?url=http%3A%2F%2Fwww.faceb ook.com%2Fpeople%2FMark-Phillip%2F712034&submit=Su bmit&http=1.1&type=GET&uak=0
You're right on time, but where is Mark Pilgrim's overwrought essay?
I thought it fitting to choose my name then:
http://www.facebook.com/window.location.href
Chris Heilmann - 13th June 2009 22:32 - #
Hey Simon, thanks for the thoughts. You nailed the motivations - the consumer implementation is primarly intended as a developer release, while we gather data, resolve bugs, and then figure out where it will be most useful to our core business metrics. There are still some core problems for OpenID that have yet to be solved, including single signout and "the nascar problem" - so rather than wait for them to be solved, we just tried to figure out a way to launch what we could without having to solve those problems.
Luke Shepard - 14th June 2009 01:55 - #
Apropos, if a declared OpenID 302-redirects to a www subdomain,
It’s interesting to consider Facebook’s history with regards to OpenID..
thanks
louis vuitton - 16th June 2009 10:58 - #
Hi there,
I tried to find a bug submit form on djangopeople web site but couldn't.
Mind me saying but comments link in this blog is not too prominent either.
Anyhow, the problem is that password recovery url in emails get 404, i.e. http://djangopeople.net/recover/Nickname/a73/the-r est-of-the-guid-goes-here
I wonder is that something which could be fixed?
Thanks!
Art - 21st June 2009 16:00 - #
Nice to see an explanation of the Facebook OpenID implementation. It confused the heck out of me :S
Not to mention the fact that it doesn't seem to work if the cookie they set doesn't stay; and since I'm hyper-paranoid and use Firefox's "Allow for session" option vigorously, I miss out (I've since added an exception). Thanks for clarifying that!
Google prepares to launch a service that indexes and ranks content from microblogging services like Twitter. Since it's very easy to post updates and the posts are usually very short, micro-blogging services are great for live blogging, posting real-time information about an event.
dofus kamas - 11th July 2009 06:11 - #
We can look to the web to see how real sites have implemented this. My favorite example is Google, Youtube, and Blogger. These are all owned by the same company, and if the user sets it up, then they all share the same identity provider (Google). However, I think to most consumers, they are branded sufficiently different that it approximates the world in which the provider and the relying party have no relationship.
Link your Blogger account with Google, then log into Gmail. Then go to Blogger - you’re automatically logged in. Now, click “logout”. You are logged out of Blogger and Google. (Incidentally, you’re also logged out of YouTube, Gmail, and all other Google services).
As another example, go to Citysearch. Log in with Facebook Connect. Now log out, and you are logged out of Facebook as well as all other Connect sites that implement automatic login detection.
çelik çatı - 15th July 2009 11:59 - #