User Experience summary for Federated Login
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%!
Email as the key
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 Hotmail, Gmail, 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 article provides more details on best practices for handling the logic of federated login, as well as the mistakes you should try to avoid
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 want to support one large identity provider such as Facebook or MySpace.
Option 1: Buttons as the guide
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:
Unless the buttons are large, they are only noticed by a subset of the end-users who could actually use them
If the buttons are large, then existing users can be confused about how they should login
If more then 2-4 buttons are shown in addition to the legacy login option, then frequently the overall registration rate on the site goes down because users are confused by all the options
If the buttons include identity providers who are not Email providers, then as mentioned above, there is no good way to identify the same person logging on through multiple paths
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).
Plan for the long term
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.
Middle of the road approach
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.
Future options
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.
Best practices and popular identity providers?
This article provides more details on best practices for handling the logic of federated login, as well as the mistakes you should try to avoid. It also includes some details on some of the popular identity providers.
What else can providers provide?
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.
For more information
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.