Facebook-connect or OpenID? From a developer's perspective

Question

I have recently been contracted to work on an application that requires Facebook-Connect as one of its authentication mechanisms.

Working on my Facebook-Connect solution, I'm realizing that it's implementing a Single-Sign On authentication scheme, where if you log in to one website, you're logged on to all of them. Personally, I'm not fond of the approach and find that it's difficult (not impossible) to work with when trying to funnel all the authentication systems through a single process that you (the developer) have some control over. I also think that it introduces unnecessary security issues (see Risks of Internet Deployment) just to slightly improve user experience.

While researching strategies to work with the technology, I have noticed that the blogosphere has all but anointed Facebook-Connect as the holy grail of authentication, echoing each others' opinion and clamoring high and strong that "OpenID is too complicated". At the same time, I haven't really seen many prominent developers and security experts raise flags or voice their opinions on the matter. My only experience with OpenID is with StackOverflow and related sites. I too had a hard time understanding what it was at first, but once I realized that I could log in with my google credentials, the experience proved to be really smooth.

Am I being paranoid or missing something that everybody got? Is Facebook-Connect really a better alternative to OpenID, or is everybody drinking someone's Kool Aid?

---

EDIT:

After working on this, I confirm that the facebook-connect login scheme is less than ideal. The whole iframe/js/cookie/reload thing is ugly and can easily become problematic. Integrating fb login to an existing authentication system is an exercise in itself. You will have to make some compromises. I'd have to write a whole other article to explain how I did it.

Facebook does seem a bit obsessed with Single Sign-On to me. Most people aren't aware that facebook has OpenID enabled for their own site, but even the way they implemented it is to emulate SSO and makes it a bit pointless. The way I thought OpenID is supposed to work: you go to a new website, if you have an OpenId account, put the url, login to your provider and you're in. You can then proceed to complete additional information.

Fb doesn't offer you the OpenID login up front. Instead, you first have to register and log in, then go to Account Settings and under Linked Accounts, pick an OpenID provider. However, unlike StackOverflow that understands the point, facebook only lets you login with yours OpenID, if you instruct your provider to remember that setting. Why? It makes it more SSO-like. If you don't check the google box that asks to remember, OpenID doesn't work on facebook.

The login aside, facebook-connect works in general, but there are still many corners to round. A few things that had me pulling my hair and curse at that api:

• the facebook documentation is scattered and not properly streamlined. Within the first hour of opening it, you will have at least 10 tabs opened in your browser. If/when you stumble upon interesting topics that you think may be useful in the future, make sure to properly bookmark them, don't rely on navigations to find them again because sometimes key articles are buried deep. I know the wiki approach to documenting api's has made lots of projects lazy lately, but common, this is facebook. They should have the means to hire a team to provide proper user guides. So, remember to have yourself a nice facebook bookmarks folder before you begin.
• There are lots of methods in the api, good luck finding an example of how to use them, you have to rely on instinct.
• many times, when something doesn't work as you wish, nobody knows why. When visiting forum pages, explanations are given in the form of hypothesis and rumors. e.g. At login, why do some applications have a pop-up login windows when others have a js modal dialog? is it possible to control that behavior? no one is sure. It is rumored that facebook is conducting some test without letting anyone know.
• not everything works as advertised. i.e. You might find yourself being encouraged to use a feature, wasting valuable time learning it, implementing it, debugging it, then only find out that it doesn't work with facebook-connect when you put it within a try/catch exception handler. e.g. feed.publishUserAction.
• facebook tries too hard to be user friendly. They waste valuable resources pushing an automagic api that only works half the time (xfbml), instead of encouraging developers to leverage their hard earned knowledge by using the more basic stuff that's proven to work most of the time (pseudo sql + html). e.g. I wasted time trying to use a combination of ajax/xfbml/js to pull friends pictures from their server. It would work for a couple of requests then stop working altogether. I then decided to pull the data directly from their db using their facebook query language (fql) and create my own markup in html. worked 100%. My advice to you if you're a real developer, don't buy into the "everything is easy" mantra that facebook tries to feed everyone, it's not. In addition to familiarize yourself with your programming platform's facebook client api (PHP, Python, Java, etc), invest into learning what you can pull from their server directly using fql and what you can do on the browser with the JS Client API (not to be confused with the fbjs). You may well find that the later 2 are all you need to do most things.

I'm sure the list doesn't end there, but from the top of my head here it is.

Answer 1

Warning: strong opinions following.

Yes, they're drinking the Kool-Aid. Facebook Connect is a proprietary, provider-dependent Single Sign-On plus more. Facebook goes down, or is deemed unworthy of trust, and you're hosed.

OpenID bypasses that. It has major user experience issues at present, but long-term it is a better solution because it frees the system from dependence on (and filtering all traffic through) a single provider. Further, its specification and implementation seem a lot cleaner -- none of this JavaScript/IFrame stuff. Just plain HTTP requests and redirects. This also gives you a lot better browser compatibility.

Facebook Connect fixed the user experience issue, but at the expense of browser support and provider choice. It's a short-term pragmatic win, but I think that long-term it's not a good idea.

Answer 2

The Single Sign-on scheme is fairly common now with major apps. If you sign into Gmail, you're signed into all of Google's products. I think it makes sense in a way, specially if the apps are interconnected, are a major service and the provider has the best security people working behind the scenes.

Now for OpenID, I think it's a great idea too, but OpenID is still not very accessible. It was supposed to revolutionize sign-in for smaller and middle rung websites, but it didn't. There are a lot of websites using it, but apparently not enough. Most websites still use their own sign-in schemes, call it lethargy or uneasiness with a separate provider.

But I think sooner or later something like OpenID will emerge but for it to work needs a major push behind it. Someone like Google.

Just imagine if you were able to sign in SO using your google ID.

For now I think you needn't be uncomfortable with Facebook-Connect,but I recommend OpenID even though I am not using it myself yet :) (lethargy)