Most websites who offer a user registration mechanism find that at least 30% of users who start the process fail to finish (if you include sending them an Email to verify their ownership of the Email address).  The percentage success rate drops even further as websites ask for more information.  One potential method for increasing the success rate is to support a federated login mechanism that automates most of the registration process and removes the need for users to remember a password for the website.  However, users have gotten very used to the standard registration & login flow, especially if they register/login to a website with their email address, so it is very easy for them to miss new options that are shown in the registration/login section of the site.  In addition, the early adopters in this space found that it was easy to design a user experience that was actually worse for users.  This summary describes some of the current best practices for medium to large sized websites.  There is also a more advanced hybrid onboarding technique which has been shown in some cases to increase registration rates to as high as 90%!

If your website already has a login system, and you begin to support federated logins, then this creates one immediate problem.  How do you identify the same person if they used the existing "legacy" login system at one point, and later use the new federated login system?  The best practice is to rely on Email addresses.  Your websites probably already requires verified Email addresses for their legacy logins.  As you add support for federated login, you can start by only supporting identity providers who can assert a user's E-mail address, i.e. Yahoo, AOL, Microsoft, Google, etc.  If the same user logs in via the two different systems, their E-mail address will be the same, and thus can be used as a global key.  This technique can also be used with E-mail or invitation based marketing to drastically increase user registration rates using the hybrid onboarding technique.

If your "legacy" logins do not yet require E-mail addresses, then you may want to consider switching to them first.  Otherwise whenever you see a new E-mail address from an identity provider, you will have to ask the user if they have a legacy account and that process has been shown to significantly hurt signup rates.  If you don't require E-mails for login, but do have some non-verified Emails for users, you can send them a one-time URL that automatically starts the migration of their login to use that E-mail address.  Another option in this case is to force users of federated login to create new accounts, even if they had been previously using the "legacy" login system.  This approach can work well for sites with small registered user bases, especially if they only one to support one large identity provider such as Facebook or MySpace.

The next challenge is how to get your current and new users to realize they can login or register using federated login.  Currently the most common option is to show a small number of buttons near the user interfaces with the legacy login and registration options.  For example, you might include buttons for Yahoo and AOL.

However, the early adopters have found some limitations with this approach:

A more general limitation of buttons is that it only allows the website to support federated logins from a very small number of identity providers.  Your website can choose to support some of the large providers that are in use by your end-users, however that is frequently only about two-thirds of a websites userbase.  Examples of websites with this approach include Plaxo, ZoHo, and Sears (click log in).

A more scalable option is to modify your website's login box to initially ask ONLY for the user's Email address, and NOT their password.  In that case, after the user types their E-mail address, your website can intelligently look at clues such as whether there is an existing account for that E-mail and whether that E-mail domain is operated by a trusted identity provider.  Based upon that information you could either prompt an existing legacy user for their password, or redirect the user to their identity provider, or offer an existing user the option to migrate to federated login if their Email provider is also an identity provider.

The user interface for this approach is the simplest, and thus tends to have very good usability.  The primary downside is that existing legacy users will need two steps to login.  However with some JavaScript techniques, the password field will still support the password autofill feature of most browsers, and in that case the login process simply changes from one click on the page to two clicks on a page that is reloaded using AJAX techniques.  We have provided a working demo of this approach as well as documentation and sample code.

If half or more of your currently registered users have E-mail addresses with trusted identity providers, then this approach will help the majority of your users.  Even if the percentage is smaller, you may want to consider running this as an experiment to see if the overall results are positive.  Over time as more E-mail providers become identity providers, the percentage of users who can register/login with one-step in this approach will continue to increase.

If removing the password from your login interface is too drastic, then another approach is to adopt the style of login box used by major websites such as Amazon and Buy.com.

With this approach, the password field is always shown.  However the additional dialog option provides some additional context for the user.  The actual dialog option that the user chooses does not actually matter in most cases.  As described in the previous sections, the E-mail address is the key thing the website needs to intelligently decide how to handle the user.  The advantage of this approach is that users with legacy logins are able to sign in with one click.  The potential disadvantage is that the user interface is more complex, however Amazon and Buy.com have obviously been happy with the results of that user interface, even without using federated login.  We have provided a working demo of this approach as well as detailed documentation.

While these options can be made to work well, there are many Internet security communities working on further improvements to the user interface.  In particular, the goal is to enable a website to detect the identity providers of the user at the browser, and then promote those options in the website's user interface.  In the most extreme example the website might detect the preferred identity provider of the user and invisibly direct them to that site to verify their identity.  Facebook, Google, and JanRain are all doing early work in this space.  However even when this works well, your website will need a user interface that it shows when the end-users identity provider cannot be automatically detected, and for that situation we suggest one of the approaches described above.

There are two classes of identity providers, those that are also E-mail providers, and those that are not.  Lets start with those that are not

The most trusted providers in that category are MySpace and Facebook.  Facebook happens to currently use a proprietary federated login API while MySpace uses the OpenID standard, however functionally the two are equivalent.  It is also possible to show users a generic OpenID button and allow them to type in a URL or domain name.  However the consistent data has shown that usage of this option is extremely low so if it is offered at all, it is best offered as an advanced option.

In the Email provider space some of the current providers as of July 2009 include Yahoo, AOL, Microsoft, and Google.  Microsoft uses a proprietary API (Windows Live ID) while the other three use the OpenID standard.  The functionallty of the Microsoft API is roughly equivalent to OpenID.  They have a preview of an OpenID provider, however it is specifically described as an "Early Preview."

In addition to those major E-mail providers, Google also hosts E-mail for a large number of ISPs, schools, and businesses.  Google operates an OpenID identity providers for those users as well.  However, your website could not include buttons for all of those domains, so to support these users you would probably need to use the second or third UI approaches described above.  An alternative is to include a button for "Google Apps" users, and then let them specify their domain, however only a small subset of these users will recognize the "Google Apps" term.

If a website is both a user's E-mail provider and identity provider, then with the user's consent they can frequently also provide additional information such as the user's name, country, language, etc.  In addition, at the same time a user is logging into a website, some providers allow the user to authorize that same website to access some of the data that provider stores for them such as their address book, calendar, photos, etc.  A user's address book can be particularly helpful if it is used to find their friends on the website, or to invite other friends.  If your website does use this feature to send invitations, another technique to improve registration rate is to detect friend's who have an E-mail address at an identity provider.  Their registration flow can be optimized to perform federated login with that identity provider.

If you would like to monitor community discussions on this topic, we suggest joining some of the OpenID or SAML mailing lists.  You may also want to review the other information on the rest of this site by using the navigation options at the left.  In particular, no matter which user interface you use, we suggest reviewing some of the advanced information about using Email in federated login.