In May 2016, we released the newest version of Google Identity Toolkit as Firebase Authentication, and in April 2019, we released Google Cloud's Identity Platform. These products include upgraded client SDKs, open source UI libraries, session management and integrated email sending service for forgotten password flows.

On June 30, 2020, the SDKs documented on this page and the API setting page will stop functioning. (The and endpoints, used by Identity Platform and Firebase Authentication, will continue to function.)

To migrate an existing project from Identity Toolkit, see the Identity Platform migration guide or Firebase Authentication migration guide.

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.


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 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 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.