The newest version of Google Identity Toolkit has been released as Google Cloud's Identity Platform and Firebase Authentication. These products include upgraded client SDKs, open source UI libraries, session management and integrated email sending service for forgotten password flows.

Sign-in flow

This document assumes you already understand the benefits of an account
chooser and email first design. If you aren't, we suggest starting with our
introduction to these topics.

The Federated Login Challenge

Federated login takes passwords out of the equation, offering significant security advantages
and reducing the burden on users. Despite these
benefits, federated login introduces a new set of usability challenges. The
primary issue arises from the need to offer several Identity Providers. Your
site should probably not only allow for Facebook and/or Google+ Sign In for two
reasons. First, not everyone has accounts at these two dominant Identity
Providers. Second, you may have existing users whose accounts have a password.
Third, many users who want to signup may be concerned about the implications of
using an identity provider. For these individuals, you may still want to provide
the option of using a password.

The NASCAR Page

Now that you support several Identity Providers as well as password accounts,
your site probably looks something like this:

In industry parlance, the style displayed above has been dubbed “NASCAR”,
because your login
page is now coated in various brands. From a marketing perspective, you may not
want the first thing a user interacts with on your site to be a billboard for
other companies. More importantly, the user now has to consider how to
authenticate. For a new user, this choice adds friction to the sign up
process. In the case that a returning customer has accounts with multiple
Identity Providers, they instead need to remember which one they used during
sign up. In practice, users frequently make duplicate accounts because they
fail to remember their initial authentication choice. To solve this usability
issues, we can once again look to the email first design.

The Google Identity Toolkit Solution

The Google Identity Toolkit leverages our user experience research to try and
alleviate the usability challenges posed by federated login. The following
diagram illustrates the various login flows a user can take through Identity
Toolkit. We will explain our design decisions as we walk through this chart.

We have already discussed how the email first design can
help test federated login on a
subset of users.
Even after rolling out federated login, separating the identification and
authentication steps can mitigate the aforementioned NASCAR issues.

On screens A and B, we begin by prompting the user for their email address. If
accounts have not been previously added to the Account Chooser, then we simply
show a text field. Otherwise, we let the user select an account from the
Account Chooser. Depending on the email address, there are several possible
next steps.

An existing user will be automatically prompted to authenticate using their
previous method. In the case that the user had authenticated with a password,
they will be directed to screen D. On this screen, the user will be prompted to
enter their previously created password. If we detect that federated login is
available for their email host on your site, then they will also be prompted to
upgrade to a federated account on screen D. If they choose to stick with their password,
multiple incorrect attempts will trigger a reCAPTCHA challenge. The user also
has the option to reset their password. If the user had instead previously used
federated login, we go to screen F to log in with their Identity Provider of
choice.

For new users, Google Identity Toolkit makes an intelligent decision based on
the user’s email address. Some email providers support a feature called Fast
Email Verification. Fast EV providers do not prompt the user for permission
when you only request to “verify” their email address, and not obtain any
private information. Frequently, the user already has an active session with
their email provider, and thus will even bypass screen F and land straight in
your app. Because we believe that the Fast EV experience is significantly
better, we automatically use it as the authentication method for any user whose
email is hosted by any domain that offers it. At this time, the only email
service with Fast EV is Gmail. For domains that do not offer Fast EV, we
surface any matching domains as the “recommended” choice.

Offering this recommendation reduces the paralysis of choice, decreasing the
friction of signing up. If the user selects the recommended option, they will
be sent to screen F. However, they may choose another provider, in which case
they go to screen G, or they may create a password account on screen E.

Rolling out Federated Login

Even with our optimized design, adding federated login to your site can be
frightening -
will everything work smoothly? How will users react? Google Identity Toolkit
lets you roll out federated login to a fraction of your users. For example, you
can give 1% of your yahoo.com users the option to sign in with Yahoo.
New users in the experiment would see Yahoo as an option on screen C.
Existing users in the experiment will be gently suggested to upgrade:

Once you set the rollout to 100%, all existing password users for the existing
domain will be shown the upgrade reccomendation for their domain.

iOS and Android

At this time, Android and iOS do not offer the same cross-app account storage
we get from AccountChooser.com on the web. Because we do not believe that
forcing users to frequently type their emails on mobile devices is a good
experience, our native SDKs do not always apply the “email first” paradigm.
Instead, they start with a normal NASCAR page:

After the user has logged in to this app before, we cache the email address to
create a local account picker for the next time they need to log in:

Account Linking

As discussed before, an email first design provides the opportunity to direct
existing users to their usual authentication method. Unfortunately, we do not
have this option for a newly installed mobile application. With the NASCAR page,
a user may accidently switch identity providers. For example, they elect to sign
in with Google+ on one device, then click Facebook sign in on another. We
believe that, in most cases, the user actually wants to reach the same account.
Thus if Google Identity Toolkit detects that the same email address was used
at both identity providers, we link the two accounts. We also ask the user to
reauthenticate through their previous method to ensure they own the account.

The combination of our web and mobile offerings provide an identity service
that runs where your service needs to be. Not only do we provide an easy and
consistent programmatic interface, but also optimize the user login experience.