Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

Are you creating a new Web site and developing a user registration system that requires new visitors to sign-up and create a user ID and password? Stop now and read this. There are now more effective approaches for dealing with Web accounts which are more powerful and are better for you and your users.

The concept of Web identity has recently undergone significant evolution that all Web developers and architects, both consumer and enterprise, should be readily familiar with today. These new identity options, specifically OpenID, OAuth, and Facebook Connect, when individually used can:

• Make it easier, faster, and safer for users to establish their identity on your site.
• Enable businesses to have single sign-on to your applications.
• Turn your site into a platform for 3rd party applications which can access user data safely and securely.
• Can integrate your site or application into the social experience of the user and their connections.

This post explores these three new ways to provide user identity that will make your Web applications work substantially better and make your users more secure and satisfied. There are also some important caveats and issues to be aware of and which we'll also discuss.

Backstory

One of the parts of the classic Web that's unfortunately still with us is the trusty old user ID and password combination, one per Web site. That's because the Internet itself has no intrinsic identity system built-in; anonymous access is the default and anything more sophisticated has to be cobbled together one-off for each site. This means most Web sites today implement user identity uniquely with different sign-up processes, user ID requirements (sometimes you get to pick, sometimes you have to use your e-mail address, and very often your favorite ID is already chosen, etc.) Then there are varying password length requirements if you are lucky, variable recovery processes if the password is lost, and so on. This is the challenge of an open, decentralized system (the Web) that has very little top-down design: How to provide users control and consistency in an online world where there are very few widely accepted user-centric open standards.

Interestingly, this is the one of the rare instances where enterprises got it right long before the Web and is now a relatively well-solved problem -- at least inside the firewall -- with something known as single sign-on. Often referred to as SSO and embodied by technologies such as Kerberos, smart cards like RSA's SecurID, and Windows Integrated Authentication, single-sign on ensures that users have just one single, consistent identity and sign-in credentials. Single sign-on works then seamlessly to enable them access to the various applications that they use on the network. There is only one user ID and password to remember and it can be reset, administered, or even shutdown centrally whenever required.

Note I say "easy to implement" is a requirement for Web identity systems and I should note that making user identity truly secure is one of the harder problems in software. This can mean that OpenID and OAuth require a fair amount of work to implement successfully. The good news: All three new identity approaches presented here are now fairly easy to use right out of the box since much of the hard work has been done to create libraries for the most common programming languages and environments. I will observe that it's still up to you, the designer of the Web application, to ensure these libraries are doing the right thing by your users. This is yet another reason why Web identity is still so often reimplemented over and over again; lack of trust of 3rd party code and not-invented here are still two powerful forces in software development. However, the value proposition has grown to the extent that these do-it-all-yourself positions are growing increasingly untenable.

That's not to say considerable care shouldn't be used. In general, the more important the user data your application handles, the more auditing and regular code reviews you should conduct of your security and Web identity libraries.

The identity options: OpenID, OAuth, and Facebook Connect

Each of the identity options presented here does something slightly different in terms of providing users with either their choice of login and Web identity or safe access to their data from elsewhere on the Web. As such, you will likely be faced not with choosing one of these three identity options but actually all three of them to give your users the options they what and will increasingly expect. I've highlighted in the past the number of core competencies that modern Web developers and architects have to master these days, and it's a tall order. These options add to that burden but as you'll see, provide considerable value in return.

OpenID

The best and most authoritative explanation of OpenID can be found here at OpenID Explained. It's quite simple: Let your users use the identity provider of their choice to login to your application instead of filling out an online form and capturing the information in a private, local account that users are not likely to trust nor long remember. Chances are nearly 100% that a user already has a valid OpenID from the many popular services that already allow their IDs to be used this way today. OpenID use is also growing: Recent reports show that sites offering OpenID logins are currently reporting that 10-15% of users will login this way and the average is climbing. Venture Beat also had a decidedly bullish outlook on OpenID today.

Many site have their business model and valuations wrapped around the number of registered users that they maintain. OpenID does NOT make this model go away, it merely provides an easier way to begin a relationship with new users. It even makes it easier for the user to interact with a new site. The full set of benefits for offering support for OpenID is:

• Faster and easier sign-up. Users get the choice of ID they prefer to use and can also choose how much information you get to see about them. You can still ask any necessary registration questions after they sign-up with their OpenID. Note also that field experiments have shown that the simplest possible registration process is 3 times more effective at eliciting sign-ups. OpenID naturally takes advantage of this fact and is the perfect complement to the highly effective lazy registration pattern. And don't forget that you still get to add the user to your local account database with all the information you care about, just in the context of their OpenID, meaning that you don't get to know their password or any other information they don't want to give you.
• Better sign-in process and lifecycle. Users only need to remember one user ID and password and so will always have an easier time logging in. It also places the burden of password maintenance and account support (at least some of it) on the 3rd party OpenID provider. And since the OpenID standard makes sure that passwords are used in a secure way and never passed along directly to sites that offer OpenID logins, users feel safer continuing to use new sites. As I've explored in the past, OpenID also potentially allows enterprises to extend their single sign-on experience out across the Web to SaaS applications that support OpenID.
• Consistent Web identity. There have been many discussions recently about namespaces as the new lock-in, particularly today's post from Chris Messina, and OpenID allows users take advantage of this to establish their own namespace consistently across multiple Web sites and indeed, the entire Web. When someone sees a given OpenID on a site, they'll know it's the exact same user they see on another site. Giving users the ability to unambiguously identify themselves authoritatively on your site will be seen as an increasingly important requirement of today's social Web.

To actually support OpenID, you'll need to implement the current specification or use one of the many available OpenID libraries that already does it for you. Support exists for all the common languages: C#, Java, Perl, PHP, Ruby, Python, and even Haskell. The bottom line, you'll be learning about digital signatures such as HMAC-SHA1 and extensible resource identifiers, or XRIs.

It should also be noted that the getting the user experience of OpenID right is essential for being successfully with it. Because most visitors will still be unfamiliar with it, a lot has been learned about how to offer the sign-up and sign-in experience in a way that is accessible and understandable. Early OpenID adopters often made the process too complicated or inexplicable to the user. A lot has been learned about how to do this correctly to enable the double digit usage rates we're seeing today on sites that are successful with OpenID. Probably the best presentation about effective OpenID user experiences is Brian Ellin's deck from this year's OpenID UX Summit, I encourage you to study it.

OAuth

Using a site through its user experience is now only one way in which the Web will interact with your service. If you're only offering a visual user experience and don't currently have an application programming interface, or API, you're behind the times. Open APIs are one of the most powerful new models for delivering services on the Web and they enable 3rd parties to integrate with and build on top of your product, creating all new services and mashups. This leverages something I refer to as Jakob's Law, which says that most of your traffic will ultimately be driven by external activities on other sites. Thus, more usage will often come in through an API than through the user interface. For example, Twitter famously has 10 times more usage through its API than through its Web experience, which I recently reconfirmed is still the case with Twitter's Alex Payne at Web 2.0 Expo earlier this month. It's also no accident that Twitter recently added support for OAuth.

However, the challenge with APIs is the same as with user experiences: How to let users access their data remotely in a safe way without having to give the 3rd party application their user ID and password for your site? Users might even feel comfortable giving their credentials for a Twitter application like Twitterific, but they certainly aren't going to do that for critical applications like e-mail, banking, or e-commerce. Enter OAuth, a method for allowing 3rd party applications to gain access to user data with their permission, but without having to give the credentials to that application. In other words, users can "authorize" 3rd party applications to access their data in your site, without giving that 3rd party application the user ID and credentials.

The benefits of securing your API with OAuth include:

• Safe, secure 3rd party data access. Users will be able to give permission for specific apps to access their data on your site without having to share their user ID and password with the 3rd party.
• Declarative control over 3rd party access. Users can also block the access of 3rd parties they previously authorized without having to have access to the 3rd party application. This gives them declarative control over who accesses their data and makes them more likely to use such applications.
• Greater use of 3rd party applications drives local use. For many applications, handing out user IDs and password to 3rd parties is unacceptable to users. They will only use the sites they trust. Since the APIs often become the dominant channel through which usage occurs, meaning that 3rd party sites can often represent the bulk of interaction if appropriate security controls are in place and users feel safe, OAuth can drive increases in usage and traffic.

You can find the OAuth specification here but most will opt to use one of the many pre-built libraries that is already available and which greatly simplify implementation. The language options are much the same as with OpenID which is good since OAuth is seeing broader and broader adoption as its benefits become clear and it gains critical mass.

Reconciling OpenID and OAuth

Now, those paying close attention to this discussion might notice that OpenID and OAuth seem in direct opposition. OpenID allows users to employ remote 3rd party logins and OAuth tries hard to make the local ID safely usable externally, at least when it comes to access through the API. In reality, OpenID and OAuth are an excellent combined strategy and plenty of work is underway to make it possible to use OAuth with OpenID. Sites that support this combination will use the user's preferred login for both the user experience (UX) of the site as well as for the API, creating a seamless, consistent experience. The Step 2 project has begun to "combine the OpenID authentication and the OAuth authorization protocols" and has involvement with many of the major players in the space including Joe Smarr of Plaxo and David Recordon of Six Apart.

OpenID and OAuth represent major, scalable Web identity authentication and authorization systems that work with both a user experience as increasingly popular API access methods. They are both open standards and have the backing of many major players, particularly OpenID which has the backing (though only partial implementation) from Yahoo!, Microsoft, IBM, Google, Facebook, and other influential organizations.

Facebook Connect

Open Web advocates are probably wondering why I've included the proprietary Facebook Connect in this discussion of Web identity. That's because there is as of yet no major social identity system that is open and has broad support. Consequently, I will warn you that using Facebook identity is something that should be done carefully with eyes wide open for the lock-in issues and dependencies that can result. However, the value proposition is considerable. For example, Facebook claims that for many sites "2 out of 3 new registrations come via Facebook Connect, and those users have about 50% more engagement on sites". This alone will be worth it for a great many services, and certainly thousands of services have agreed.

By social identity I'm referring to not just a user's individual identity but also their social graph, or list of connections they've established online, as well as the communication that takes place between those contacts, typically an activity stream.

Social identity is fast becoming essential context for for online applications; it's not just enough to have you as a registered user since today's Web applications also need to know who your connections are in order to provide the services they offer for communication, collaboration, etc. Social identity systems allow you to login and then be able to refer to and access your social connections and communicate with them. This is far preferable to the old-school equivalent: Importing your contact lists and then inviting all of them to the new application you're using. The days when that was acceptable are over, if they ever were. Now you can just use your social identity and they can see what you're doing in their activity stream and decide whether or not to respond or participate.

For example, I use the video sharing site Vimeo quite often but many of my friends don't and don't even have an account there. But they can see what I'm doing on Vimeo with my Facebook Connect link that shows my videos in their Facebook activity streams when I post them. They can then decide if they want to view the video or otherwise interact with Vimeo.

Facebook Connect itself is a simple set of JavaScript libraries and XML markup that allows you to enable users to connect to their Facebook accounts from within your Web application. The capabilities and advantages of Facebook Connect are:

• Single-click login. Users can log in with their Facebook identity and allow your site to access their Facebook profile.
• More engagement. Use a user's personal interests to provide more relevant information and offer customized content from friends.
• New distribution models. Users can share content and actions taken on your site with contacts back on Facebook through the activity stream and other social communication channels on Facebook.
• Direct access to Facebook. Use the APIs that have allowed more than 700,000 developers to build tens of thousands of applications.

Getting started with Facebook Connect is relatively easy and the startup guide is straightforward. The integration is very platform-agnostic and requires little implementation for basic capabilities though it does use proprietary JavaScript libraries and XML markup. To get the most out of Facebook Connect will require deeper integration however, and this will create more dependencies on how Facebook manages social data and activity information. Fortunately, most good architects will be able to create a straightforward separation of concerns and one that will allow other social identity systems to be plugged in as they emerge, especially on the open side, such as Plaxo's Open Social Graph.

While many organizations remain uncomfortable delegating any aspect of user identity to external services, the reality is that online services are invariable stronger, more robust, and more attractive to users when they do. The effort is higher however, and there are more dependencies to manage but Web identity has definitively entered a near era. Proactive companies that take advantage of what is possible today will be poised to enjoy additional growth, higher user retention, and better customer relationships.