Facebook Connect, OAuth and OpenID: The differences and the future

With today’s announcement from Facebook of its plans to take its Facebook Connect program into the mobile sphere with Single Sign-on, it started to raise some questions from across various points. On Twitter, we heard questions like “what’s the difference?” and in emails I’ve talked at length with a few people who have great understanding and interest in the battle for “one login”.

So we thought we’d take this opportunity to clear the air on a few things, to get you up to speed about what’s going on in the login market. With so many choices, it can certainly get confusing. Even here on TNW, we offer you the ability to use your Facebook account with Facebook Connect or Twitter via OAuth to sign in to the site.

What They Do

To start, you need to understand OpenID and Facebook Connect essentially serve the same purpose in respect to identification, with different feature access separating the two. As far as identification goes, instead of having to sign up on a site and remember passwords, you simply sign up once and then you can use that login across a myriad of sites.

The problem that we’ve seen with ID is that different sites have had different desires and as such different standards have evolved. Also, it pays to understand that the decision to use one platform over another, in many instances until now, has essentially devolved simply into a question of how much information you need.

OpenID

OpenID is an old standard. In fact, it hasn’t even been updated since 2007. In its path, however, it has picked up some great sites. For that matter, even Facebook allows you to sign in and use its site via OpenID and users can link their Gmail accounts to the site in the same manner.

The purpose behind OpenID can best be described as an introduction to a stranger. OpenID serves as the third party that can verify who you are. So, when you go to sign in to a new site, the site asks the OpenID server “is this John” and the OpenID server replies that yes, it is John.

The problem with OpenID, according to Dave Recordon, is that v2 of the standard was incredibly difficult to implement:

I’ve heard story after story from developers implementing OpenID 2.0 who don’t understand why it is so complex and inevitably forgot to do something.

So, combine that complexity with the fact that OpenID hasn’t been updated in 3 years and you have a bit of a recipe for disaster. There’s also the problem that it requires more than one handshake (introduction) in order to get data stored on a server. In fact, OpenID cannot, at this point, acquire that information on its own. It has to send a second request for OAuth to handle the information transfer.

There is hope on the horizon, however. Rumors are swirling that OpenID is working on a new standard called OpenID Connect that will be built on top of OAuth. This would allow a single handshake for both identification and data transfer. We’ll do another post about that, later, as more developments happen.

OAuth

In a few words, OAuth is “a simple way to publish and interact with protected data. It’s also a safer and more secure way for people to give you access.” Twitter has implemented it, with the @anywhere platform, as have a number of other sites around the Internet. Version 2 of OAuth, released in May of 2010, is a complete revision of the platform that is purposely not backward-compatible with previous iterations.

OAuth differs from OpenID in that it cannot request identification (at least in its present form). What it can do is allow a 3rd party to have access to your data without the need for you to show your password to that 3rd party site. There is a revision to OAuth that has been proposed, allowing OAuth to acquire identity as well, but it is far from finalized.

That 1.0 version of OAuth had issues of its own. In fact, it spawned the discussion about WRAP, yet another manner of doing the same thing. While the WRAP discussions have gone to the wayside, you can rest assured that the involved parties are watching the current circumstances quite closely.

Facebook Connect

The other major player in this game is Facebook. Instead of simply using OpenID or OAuth, Facebook brought about Facebook Connect. Why, you might ask? Essentially it came down to the fact that neither OpenID nor OAuth could offer the depth of information that Facebook wanted. Instead of just offering credentials, Facebook wanted to offer friend access and dynamics to the privacy of the information that simply wasn’t possible with the other standards.

With Facebook Connect, what we see are elements of both OpenID and OAuth. Facebook Connect can verify that you are who you say you are, and it can then provide access to your data once you’ve given it permission to do so.

Today, with Facebook pushing its Single Sign-on project, that Connect option moves into the world of mobile, where OAuth and OpenID have had issues gaining ground.

So What’s Next?

That’s a question that nobody has been able to answer, just yet. OpenID and OAuth think that they have a collective right answer, but Facebook clearly thinks that it has its own. As Louis Gray told me in a discussion about the subject, it will likely come down to adoption. The dominantly-adopted platform will be the one that pushes the rest aside. At this point, that is likely Facebook Connect, but there are literally millions of other sites that use the others.

We’ll be monitoring this situation, moving forward, and keeping you up to date with what happens. For now, I have to send out a huge measure of thanks to Louis Gray for his deciphering of information as well as his insight into the subject. Another massive amount of respect goes out to the crew from Baydin Software (hooray for Boomerang!) for putting things into laymen’s terms.