Last Thursday I dropped in to the Google SIPB hackathon, where I got a chance to chat with several Googlers in the Cambridge office about the whole ecosystem of decentralized identity and social networking services. I had actually previously spent a bit of time searching for a high-level map laying out how these various services related to each other, strictly out of curiosity, but never really found anything that was succinct, clear, and free of BS. There also seems to be a lot of contradictory information and general confusion. Along with the recent news expecting similar service stacks from Twitter, it seems timely to share all the things I’ve been learning.
The executive summary:
- OpenID: authentication; use one login across many sites
- OpenID Attribute Exchange: a key-value store protocol for OpenID
- OAuth: authorization and authentication; grant sites specific access to your account
- OAuth WRAP: a simpler OAuth that leverages PKI instead of its own signature scheme
- OpenSocial: a standard API into social networks
- Google Friend Connect: an OpenSocial router, plus a bunch of other less-important stuff
- Facebook Platform: all the above (and a bit more), for the Facebook stack
- Facebook Connect: establish links between Facebook and third-party user account systems
- Portable Contacts: just the slice of OpenSocial that deals with contacts
OpenID (Wikipedia) provides an authentication service standard. Users obtain a globally unique identity (a URL) from an OpenID provider. You can think of this as a login username, but which you can use anywhere. When you want to authenticate yourself as this user (prove you’re the owner of the URL), you log in to your OpenID provider, instead of logging in to the sites that use OpenID.
OpenID’s foundation was largely driven back in the day by LiveJournal, so that you could use a single identity under which to leave comments at any blog.
I’m going to allow myself to get slightly derailed talking about some security aspects of OpenID.
To briefly illustrate how the protocol works, consider the scenario of logging into StackOverflow (the “consumer”) with an OpenID:
- You provide your Google OpenID URL.
- StackOverflow contacts Google to establish a shared secret key (using Diffie-Hellman).
- You log in to Google and get back a message signed with the shared secret key (usually using HMAC-SHA256).
- You forward this message to StackOverflow to prove that you logged in successfully.
That’s the first approach the protocol defines; it requires the consumer to be stateful (to remember the shared secret key). The other approach lets the consumer be stateless:
- You provide your Google OpenID URL.
- You log in to Google and notify StackOverflow that you succeeded.
- StackOverflow contacts Google to verify that you logged in.
The first (stateful) approach begs the question: instead of exchanging shared secret keys, why not just use PKI (i.e., google.com’s TLS certificates)? I’m guessing OpenID doesn’t want to force providers to get (reputable) certs. In fact, OpenID doesn’t require TLS in its interactions, and hence doesn’t prevent MITM attacks between the provider and consumer (though it does encourage TLS). But OpenID Connect proposes (among other things) building on top of OAuth WRAP (and hence PKI).
Security researchers have raised objections to OpenID’s susceptibility to phishing. Normally, a phishing site needs to lure the user into visiting a (fake) login page (usually by suggesting some problem with their account), but with OpenID, users expect to be taken to a login page:
In the standard case, I (the phisher) have to make my website look like the Real Website and persuade you to go to it somehow – i.e. con you into thinking I am the real Paypal, and your account really has been frozen (or is that phrozen?) and you really do need to log in to unphreeze it.
But in the OpenID case I just persuade you to go anywhere at all, say my lovely site of kitten photos, and get you to log in using your OpenID. Following the protocol, I find out where your provider is (i.e. the site you log in to to prove you really own that OpenID), but instead of sending you there (because, yes, OpenID works by having the site you’re logging in to send you to your provider) I send you to my fake provider, which then just proxies the real provider, stealing your login as it does. I don’t have to persuade you that I’m anything special, just someone who wants you to use OpenID, as the designers hope will become commonplace, and I don’t have to know your provider in advance.
One solution is to make clients validate the set of legitimate OpenID providers. From Ben Laurie’s follow-up post:
My friend, Adam Shostack, muses
It seems to me that if my local software knows who my ID providers are, rather than being told, then the problem goes away?
Indeed, but OpenID’s ground rules are that you should not need local software, and this is the nub of the issue.
This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software. In an ideal world, this would be a standard component of browsers, but it isn’t. Why? Well, the reason is fairly apparent: the best general way to handle this problem is through zero-knowledge proofs. SRP is an often-quoted example, but there are many simpler ones. However, various (already rich) greedy bastards have successfully blocked wide deployment of these protocols in a cynical attempt to profit from patents that (allegedly) cover them. Sad, I think, that the world continues to suffer whilst a few seek a drop in their ocean of money. Since these general (and, I should add, very simple) solutions cannot be deployed, we end up with purpose-specific plugins instead of general-purpose mechamisms.
Ben is also involved in the OpenID Provider Authentication Policy Extension (PAPE), which helps a bit by allowing you to determine the authentication methods used by an OpenID provider, so that you know which providers to use (which ones use unphishable authentication). Brian Kelley provides a good overview.
OAuth (Wikipedia)—a standard largely initiated by Twitter—provides authorization. It allows users to grant and revoke controlled, third-party access capabilities to their account. Instead of giving out your username and password, which results in unrestricted access to your account, you can hand out OAuth tokens to access the account in a specific way and for a specific time duration. E.g., you can grant TwitterFeed permission to post tweets to your Twitter account.
OAuth WRAP is a simplified version of OAuth that replaces signatures with TLS (in a fashion similar to what I discussed above in the context of OpenID).
OAuth is often touted as being complementary to OpenID, but granting access implies that the user has authenticated with the identity of the account that the OAuth site is accessing. Furthermore, OpenID Attribute Exchange (AX) is an extension to OpenID that allows for gets and puts on an account-associated data store (attributes), which starts to overlap with OAuth functionality.
- Adding and removing friends
- Adding and removing apps
- Storing activities
- Retrieving activity streams for self and friends
- Storing and retrieving per-app and per-app-per-user data
Google Friend Connect
Google Friend Connect (GFC) is a proprietary system built on top of OpenSocial, that turns your site into an OpenSocial container. I.e., by embedding GFC, your site gets its own social network. But rather than having the user re-create their profile information and social graph in yet another online social network, GFC allows users to link their profile on your site to one or more profiles in other social networks.
From the docs:
- Every site that includes Google Friend Connect in any fashion instantly becomes an OpenSocial container.
- When visitors “Join” the site they become members and can either create a profile or use a profile from other social networks.
- The visitors can optionally link in existing social networks that are integrated with Google Friend Connect.
- This forms a site-specific social network consisting of the site’s members, their friends and friends-of-friends that conforms to the OpenSocial API.
- As a developer you use the OpenSocial API to integrate this social data without needing to know its multiple sources and endpoints.
GFC gadgets are OpenSocial gadgets, but with a few key differences:
- Site owners decide what gadgets to include in their site, not the visitor.
- Many of the visitors who visit the site never login, so your gadget needs to have a UI and presentation model that work for signed-in and unsigned-in visitors alike.
- OpenSocial people roles have a different mapping than in standard social networks. Read OpenSocial and GFC for a more detailed explanation of these differences.
There’s also a hodgepodge of other things packed under the Google Friend Connect name:
- a set of easy-breezy wizard-like tools for integrating Friend Connect into your site without programming
- surveys and newsletters
- a gallery of GFC gadgets
- tools for feeding user information into AdSense
- plugins for various “social” software systems (CMSs, blogs, etc.)
The Facebook Platform provides a similar stack of services, all bundled for a single provider/network. It allows applications—websites, desktop, mobile, applets—to be written on top of the Facebook social network. It provides authentication, authorization, and access to the social graph, activity stream, and user info.
There are differences, of course. For one thing, the Facebook Platform boasts features—photos, events, videos, and so on—that aren’t baked in to any open standards-based counterparts. Whereas OpenSocial applets are written using the Gadgets API (which uses its own markup language), Facebook applets are written using XFBML. But from a high level, these are two largely overlapping stacks.
Also, a quick point on phishing from Dare Obasanjo’s overview:
If OpenID phishing is a concern now when the user is redirected to the ID provider’s site to login, it seems Facebook Connect is even worse since all it does is provide a pop over. I wonder if this is because the Facebook folks think the phishing concerns are overblown.
Facebook Connect has been a point of confusion, because a bunch of sites claim it provides the authentication and access from third-party websites, even though these had always been possible via the Platform API. And for linking accounts (if you wanted to establish an association between a user’s account on your site and the user’s Facebook identity), you could simply track this in your application’s own databases, as you would with OpenID.
It turns out that Facebook Connect is several small things. There’s nothing particularly special about Facebook Connect sites, since the documentation really just has you create a Facebook application that is a website. In the context of the Platform API, it is just a subset of the API that allows Facebook to track users on your site, and hence, account links. Namely, it consists of three functions:
Connect.registerUsers: identify your users by their email addresses
Connect.unregisterUsers: remove users
Connect.getUnconnectedFriendsCount: count of users you identified that have Facebook accounts but have not associated
The real value-add here is that once Facebook knows about unconnected account links, it can then suggest for the user to connect the accounts, boosting your site’s exposure through the social network. Besides this, Facebook Connect provides a similar tool to Friend Connect’s simple integration wizard.
The goal of wire-aligning our specs but keeping them independent was to “have our cake and eat it too”–if you’re already supporting the OpenSocial RESTful protocols, you become a Portable Contacts provider “for free”, but if you just want to do Portable Contacts and you’re not in the “OpenSocial camp” for one reason or another, you can do that too. I think it does also provide clarity about the scope and focus of Portable Contacts, which as you mention spans both address books and social networks, and is narrowly focused on the problem of easy and standard access to that people data.
One could make a similar argument about OpenID (authentication) and OAuth (authentication + authorization).
MySpace Open Platform presumably provide a set of similar services for the MySpace platform.
<flame>But MySpace is dying, so the non-standard access methods are not going to matter.
</flame> What matters is their gung-ho adoption of standards, including OpenSocial, OAuth, OpenID, Google Friend Connect.
OpenID Connect is a half-baked idea that calls for what sounds like another OpenSocial. It’s not worth discussing, but for completeness I’ll include the only informational quote:
OpenID Connect is OpenID rewritten on top of OAuth WRAP using service discovery to advertise Portable Contacts, Activity Streams, and any other well known API endpoints, and a means to automatically bootstrap consumer registration and token issuance.
All these standards can be pretty overwhelming to any newcomer to the scene. And although this write-up helped me (and will hopefully help others) sort things out a bit, the many overlapping standards are making the space feel especially crowded. Dare Obasanjo offers some perspective on the current state of affairs:
So do we need an OpenID Connect? We would if there were lots of Facebook Connect style offerings that significantly differed in implementation. However there aren’t. One could argue that perhaps the reason we don’t have many is that there are no standards that guide websites on what to implement. However this sounds like using “standards” for inventing technologies instead of standardizing best practice. I’ve always considered this questionable from my days working with XML technologies XML Schema, SOAP and WSDL.
If you got together to create an OpenID Connect now, the best you could do is come up with a knock off of Facebook Connect using “Open brand” technologies since that’s the only example we have to work off of. That’s great until Facebook Connect adds more features or websites finally wrap their heads around this problem space and actually start competing with Facebook Connect. Premature standardization hinders instead of helps.
Follow me on Twitter for stuff far more interesting than what I blog.