In the early days of my programming career, I specialized in a few key areas. As part of the process of building online communities and internal search engines, I constantly found myself having to build what we termed “transparent login” systems. These duct-taped solutions provided users with a seamless authentication scheme for surfing from one secure website to another one that was built, hosted and maintained by different teams, organizations, or companies. Not only did these schemes address the multiple login issues that came with integrating multiple secure websites, but they also solved issues around server state, or persistence.
As an example, we may be in a healthcare portal which feels like a single site, but in the background is actually three or four different sites which were built and maintained by completely different teams, usually by completely different companies. The backend systems that ran these websites did not connect and would never be connected. However, we were building online communities that required specific personal data from the authenticated user.
These transparent login systems typically consisted of a few database tables in a SQL Server database that did nothing more than store user login information from all the different sites the user was traveling to and from in our little online partner ecosystems. We would write code that checked to see if the user in question was allowed access to the data systems from a partner organization which we needed information from in order to complete the process of building and displaying a webpage. If they were granted access by the other system, we would log them in via the programming code in a background process as opposed to making them login manually. This was intended as a solution for a user experience requirement more than anything else. We couldn’t effectively cast the illusion that a user was surfing on a single website or portal if they were being required to log in as they traversed across different domains.
Simply put, authentication is the process of validating that an unknown someone, from a trusted source, is who they say they are. So this process of having to manage users’ authentication schemes became more prevalent as companies and organizations created more complex, interrelated networks of websites. Today this issue is not locked behind the firewall of enterprise intranets. We now have legitimate authentication, usability, and data portability needs on the open internet. These needs can surface on business, social, informational, and educational websites alike.
Enter the “identity” movement. These are groups of people who started to look for a standardized way of building open systems to deal with the growing need to manage identity, access, and control of computer systems across multiple internet properties and domains. While many solutions have been created that take a healthy stab at solving the problems described above, none have been standardized. Moreover, the ones that could be considered “standard” and “open” tend to lack the support and/or features which would provide programmers and user’s alike with a compelling reason to adopt one system over the others en masse.
On May 9, 2008, Dave Morin, a Senior Platform Manager at Facebook, announced Facebook Connect, on the Facebook Developer’s Blog (http://developers.facebook.com/news.php?blog=1&story=108). Facebook Connect, while not open, is Facebook’s answer for a standard authentication service that competes with several “standard” authentication systems like OAuth, OpenID, Open Social, Windows Live ID and others. More details were made public about the set of API’s on July 23, 2008 at Facebook's annual conference for developers before the system was made available to users in December of 2008. The service enables Facebook users to login to affiliated sites using their Facebook account to share information from such sites with their Facebook friends.
The service, also known as a single sign-on service, enables Facebook users to login to non-Facebook sites using their Facebook account credentials. They can then share information from Facebook with their Facebook friends who use the same non-Facebook website, blog or social network. Facebook Connect’s identity management system should not be confused with models based upon “federated identity,” such as OpenID. We’ll discuss these other authentication services.While most people simply associate authentication services with a unified method of managing their sign-in activity across several websites, Facebook Connect does much more than simply letting users log in to a site by validating their identity via their Facebook account. When logging in with Facebook Connect, users bring their Facebook profile data with them. This means the website or blog they just logged into can allow them to find their friends who also use the same site. Furthermore, they can share information and experiences using the same features as they would on a Facebook application. With Facebook Connect, almost every feature that you can build with an application on Facebook can be offered through a third-party website or application using the service.
Several Of The Top Competitors
OpenSocial
On November 1, 2007, Google, Myspace and several other social networking companies released this set of common application programming interfaces (APIs) specifically for authenticating across web-based social network applications. Websites and applications that utilize OpenSocial are interoperable with any social network system that supports them. OpenSocial’s foundation is based upon the Google Gadgets framework, HTML and JavaScript. Via its API’s OpenSocial exposes general people, relationship, and user activity information. It also provides a JavaScriptAPI and effectively solves the challenges around persistence, or server state. While OpenSocial provides more information about authenticated users than most of these solutions, it still does not provide as much information about users as Facebook Connect does.
As of this writing, the OpenSocial Directory (http://directory.opensocial.org/gadgets/directory?synd=cad) listed over 17,000 websites and applications that utilize the OpenSocial APIs including Google, LinkedIn, Hi5.com, MySpace, orkut, Netlog, Socialtext, Sonico.com, Friendster, Ning and Yahoo!.
OpenID
OpenID is an open, federated standard for authenticating users on a website, social network, or blog. When we mention “federated” systems, we are referring to authentication processes deployed or distributed across multiple computer systems The model was intended to require OpenID to replace the common login process whereby a user enters a username and password to access the website in question. After a user authenticated themselves via OpenID once they should be able to gain access to the resources of multiple software systems. As defined, this has never been my experience with OpenID, or for that matter, any other of the identity management systems mentioned here, except for Windows Live ID and to some extent, Google Friend Connect. We’ll get to those systems a little bit later in this discussion.
OpenID’s authentication process comes in the form of a unique URL. My OpenID provider is “www.myopenid.com” - which means, my URL looks like “http://xxxxxxxxxxxxx.myopen.com.” You use this URL in the place of a username. So right off the bat, I am not finding the process more efficient as I have to type in over twenty-five characters in place of my username, which has in the past been under ten characters. After you type in your URL schema and click submit, you are passed along a page on the website of your OpenID provider where you are asked to submit your password. More efficient than the old, disconnected method of logging in? No. After you provide your correct password, the provider redirects you back the the original website you were logging into so you can go about your merry, authenticated way.
OpenID succeeds at federalizing your online identity credentials by not relying on a central authority to authenticate a user's identity. It also succeeds at standardizing non-standard forms of authentication such as smart cards or biometrics. However, it fails at usability and persistence.
One case in point: Once I have authenticated to one website using OpenID, say AOL, I would expect to not have to log in again when I visited another site that supports OpenID authentication such as the BBC’s website or MySpace. In my experience, this is not only not the case, but OpenID has a spotty record when recognizing that I should be pre-authenticated when I am come back to a website after a couple day’s absence. Companies who support OpenID include AOL, BBC, Google, IBM, Microsoft, MySpace, Orange Telecom, PayPal, VeriSign, Ustream and Yahoo!.
OAuth
Windows LiveIDWindows Live ID has also been known as Microsoft Wallet, Microsoft Passport, .NET Passport, and the Microsoft Passport Network. This service, obviously created by Microsoft, allows users to log in to multiple websites using a single account. You’ll find LiveID on Microsoft-owned sites like Hotmail, Live.com, Bing.com, MSNBC, MSN, Xbox 360's Xbox Live, the .NET Messenger Service, Zune and MSDN. However, there are a few other websites that us it as well.
Google Friend Connect
Google Friend Connect operates in a similar fashion as does Windows LiveID, but with Google properties and partner websites. In a move that creates complexity and confusion in a market place driven by the need to simplify, Google Friend Connect is actually an OpenSocial application. It uses OpenID for sign-in and oAuth to control data.
Yea! An authentication service that is built upon several other authentication services. I’m about to open up the dictionary, find the word “standard” and send off a terse email to someone. I’m hoping that you, dear reader, have realized that the dream for a federated single sign-on and authentication schema has long passed us by, at least in this generation of “solutions.”
A couple of standout benefits of using Google Friend Connect? It is simple: it requires no knowledge of web programming and Comment Translation: it provides English translation services for comments left in any non-English native language. Google Friend Connect integrates social applications and content from Hi5, Orkut, Plaxo, MySpace, Google, and other social networks.
So let’s look at the differences between a couple of these front-runners and Facebook Connect.
OpenID (as do most of these systems) has an identity crisis. There are a plethora of new solutions coming out on a regular basis. This necessarily requires an “authentication service Darwinism” to weed out the weak and under utilized services. If this does not occur, then all these “solutions” are doing is adding exponentially to the noise in this area. So, considering that many of these services are going to die on the vine, users and website owners need to carefully consider where they are going to devote their resources and entrust their information. Let’s face it: Facebook isn’t going anywhere. Considering a service that has the commercial backing, consumer trust, and acceptance that Facebook has, it’s difficult to consider anything else. Not impossible, but difficult.
oAuth, one of my favorites from this list, does not require users to maintain a third set of credentials at all between sites. It simply connects user accounts between websites. This is great for ease of use, however it does not solve the single sign-on problem. oAuth still requires the user to create and maintain user login credentials on all integrated website. If properly implemented, Facebook Connect actually allows new users to bypass the account creation on third-party websites by associating their Facebook credentials with the consuming website.
Another Facebook advantage: The data provided by Facebook on a user level unmatched by other authentication schemes. That data, since it is maintained on a regular basis by its users, will be more accurate and up to date. To be sure, Microsoft and Google have the potential to easily match this by coming toe-to-toe with the Facebook API and making theirs more open and extensive. However, as of this writing, that have not done so and that gives Facebook a clear advantage in the eyes of the programmer and consumer.
Is Facebook Connect right for you? Unfortunately there is not a “one-size-fits-all” answer here. You’re going to have to look at the different options we’ve summarized above and make the call yourself. I will note for your consideration that making users maintain several different universal login schemas in the form of OpenID, OpenSocial, Google Friend Connect, Windows Live ID and others does not solve our multiple sign-on, multiple authentication problem, it exacerbates it. Most users will already have either a Google account, Windows Live ID (in the form of one of a myriad of the online Microsoft services offered over the past decade), or a Facebook account. This reason alone is enough in my eyes to seriously consider any of the authentication solutions offered by Facebook, Google, and/or Microsoft above the other, smaller competitors.
If it helps at all, because of the different features, the audiences I interact with, and usability considerations, I allow for a hybrid approach, using Facebook Connect, oAuth, and Windows Live ID. On the sites where we use third-party authentication, I allow the user the option to select the identity management platform they are most comfortable using (within those three). Admittedly, this isn’t a perfect solution by any means. However, until we get a truly open, standard resolution which actually provides for a federated, single sign-on solution that provides true data exchange and portability, we have to pick form the potpourri of quick-fixes available to us today.In the end, I’m hoping that the irony of all these different well-intentioned groups creating different “standardized” services meant to simplify the log-in process for all of us hasn’t been lost on you.
This post is from a draft for "Facebook Marketing - An Hour A Day." I am writing it with Chris Treadaway for Wiley Press (Sybex). The release date is February 26, 2010. You can reserve your copy now if you like.
