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, 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. 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:
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. Which providers to trust? 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. 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. |