Facebook Connect vs OpenID: how social login won

In 2008 two ideas for ‘one login for many websites’ were running side by side. One was an open standard, OpenID. The other was a product from the biggest social network, Facebook Connect. Within a few years the product had won. The story explains much of what we now take for granted when a website offers ‘Continue with’ buttons.

Two ways to the same goal

OpenID was a protocol. You picked any provider, or ran your own, and a website that supported OpenID would let you sign in with it. Nobody owned the system. The cost was choice: the user had to know which provider they had and, in the original form, often to enter an identifier such as a web address. OpenID 2.0 describes the mechanics.

Facebook Connect was a product. Facebook unveiled it at its developer conference in July 2008 and made it widely available in December 2008. A website added a Facebook button, and visitors who were already logged in to Facebook could sign in with one click. The site also received a name, a photo and, with consent, the user’s friends. There was one provider and one button, and the brand was already familiar.

Why the button won

Several things combined.

• A single choice. ‘Sign in with Facebook’ asked no questions. OpenID’s problem was often called the ‘which provider?’ problem. Users did not remember what their OpenID was, or even that they had one. The detail is covered in Why OpenID 2.0 faded.
• Rich data and social features. A site wanted more than proof of login. It wanted a profile and a social graph. Facebook delivered both. OpenID’s attribute exchange was optional and thinly supported.
• A company pushing it. Facebook had developers, documentation, support and a commercial interest in being the identity layer of the web. OpenID depended on volunteers and on corporate members whose priorities differed.
• Familiarity. People already used Facebook every day, so logging in with it felt natural.

OpenID did not ignore Facebook

OpenID’s leaders did try to connect the two worlds. Facebook joined the OpenID Foundation in February 2009 and launched relying-party support in May 2009, which meant users could sign in to Facebook with an OpenID. That was symbolic more than decisive. The Facebook button, not OpenID, remained the way most sites integrated with the network. Meanwhile Google, Yahoo and Microsoft had joined OpenID in 2008, as described in Big tech joins the OpenID Foundation, but a provider only helps when websites accept its logins, and many sites were slow to add OpenID buttons.

One small 2008 detail shows how quickly the market shifted. In September 2008 the password manager Passpack added Facebook to its list of accepted third-party logins, next to Google, Windows Live and Yahoo. See Passpack and OpenID in 2008.

What it cost

Social login brought convenience, but also dependency. If your account at the provider is suspended, you may lose access to every site that used it. The provider can see which sites you use. Sites may receive more profile data than they need. After a series of privacy scandals around 2018, Facebook tightened what its platform shared with outside apps, and many sites reconsidered how much they relied on one network’s login.

The design question that OpenID had asked, who should hold your identity, did not go away. Apple answered with Sign in with Apple, which lets users hide their email address, and the EU answered with the wallet, where the state and the user, not an advertising platform, hold the credentials.

How it works now

Under every modern social-login button sits OAuth 2.0 for permissions and OpenID Connect for the identity statement. In other words, the open standard survived, but as the plumbing of the commercial buttons. A practical guide to using them safely is Sign in with Google or Apple. For the dates, see the OpenID timeline.

Facts on dates come from public records of Facebook’s developer platform and the OpenID Foundation’s history, as summarised in October 2026.