General Availability of Google Sign-In for the Assistant

Posted by Silvano Luciani, Google Assistant Developer Programs Engineer

Starting today, Google Sign-In for the Assistant is coming out of developer preview and is generally available. This means you can now use a seamless sign-in experience for your users in your Actions. This is a new type of account linking that’s easy to implement and offers a great experience for your users.

In this blog post, I’m going to talk about the different account linking options that Actions on Google now offers and cover some considerations you should keep in mind for each of them. For more details about each of the flows, check out the revamped account linking docs at developers.google.com/actions/identity.

Before we get into more details, let me also recommend that you watch the talk Adam Dawes (Google Identity product manager) and yours truly gave at Google I/O 2018: Personalize Actions for the Google Assistant. It’s a good primer on why it’s important to personalize your Actions, what options are offered by Actions on Google, and how account linking fits into the personalization story.

What is account linking?

With Account Linking, your Action can easily welcome back users by their name, and share identities with versions of your app on other platforms.

You can use account linking to ask the user to give your Action access to their profile data, like the user’s email and unique Google ID. You can then use the email or the Google ID to associate your Action’s specific data with the user. For example, if your Action offers a catalog of podcasts, you can use account linking to save the user’s favorite genres or radio stations in your database using the account email as a key.

There are two main cases to consider when deciding which type of account linking to implement:

  • If your Action is available only on the Assistant and doesn’t have companions on other platforms (for example, a Website or Android app that your users also can access).
  • If your Action does have companions on other platforms and you want to keep a state associated with the user across these different platforms.

If you fit the first use case, Google Sign-In is the best account linking choice for you. If you fit the second, then OAuth and Google Sign-In together is the best account linking choice. Let’s see why in more detail.

Account linking with Google Sign-In

With Google Sign-In, after the user gives consent to share their profile with your Action, Google will send you an ID token that contains the Google account data of the user with each subsequent request. The ID token is a JSON web token signed from Google; after you verify and decode the token, its content looks like the following:

Example of the content of a Google ID Token.

The first time the user goes through the account linking flow, you can use the user’s email address or the unique ID of the user’s Google account to do the following:

  • Find a match in your user’s database if they’ve already used your Action and linked their account.
  • Create a new account using Google’s profile information.

Overall, this flow is my favorite for the following reasons:

  • It’s very easy to implement. All you need to do is add the code to start the flow and verify and decode the ID token. You can find instructions on how to verify and decode an ID token using our client libraries here.
  • It guarantees completion of the flow over voice. All the steps of the flow can be completed over voice without needing to ask the user to interact with a screen (for example, the user doesn’t have to sign in to your authentication web site). This greatly reduces friction and can increase the conversion rate for sign-in for your Actions.

You may be asking yourself, “If it’s so easy and cool, why not use this all the time?” Consider the following scenario: your Action allows users to place orders at your coffee shop by saying “order my favorite,” for example. You also have a loyalty program which allows users to collect points for each order they make and collect free drinks when they reach a certain amount.

If I’m an existing user, and I signed up on your Android app using a personal email like “silvano@luciani.com” and not my Google account, and then went and used Google Sign-In in your Action, I wouldn’t be able to link my existing account. This means I wouldn’t be able to access my preferences like all my favorite drinks and my accrued loyalty points there, either! Enter OAuth and Google Sign-In.

Account linking with OAuth and Google Sign-In

With OAuth and Google Sign-In, you add OAuth-based account linking as a fallback for those cases where you want to link to an existing non-Google based account. OAuth is the industry standard for authorization and allows you to redirect the Assistant user to your authorization website, where they can sign-in using their existing non-Google account.

When you use this account linking type, after the user consents access to their Google profile, Google sends a request to one of your endpoints (the token exchange endpoint) to check if the Google user already exists in your authentication system. If not, you can redirect the user to your authorization web site and complete a standard OAuth flow.

While this solves the problem of linking a non-Google account, there are a couple of downsides to consider.

  • You need to have a working implementation of an OAuth server that also supports Google’s extensions to the protocol. This is definitely more work than what is required by the Google Sign-In flow.
  • Going through the standard OAuth flow requires a screen. This means a user that started the interaction with your Action on voice needs to be transferred to a phone, which increases friction and can reduce the sign-in conversion rate.

Account linking with OAuth

Lastly, you can use traditional OAuth2-based account linking; however, with the option to use Google Sign-In, or Google Sign-In and OAuth together, there isn’t much of an incentive to do it. This flow requires the extra work of setting up a working implementation of an OAuth2 server and requires transferring the interaction with a user to a screen, which, as mentioned, can increase friction and reduce your sign-in conversion rate.

You might still want to consider using this flow if you already have a working implementation of an OAuth server, and you can’t extend it to add support for Google’s proprietary extensions required for the OAuth and Google Sign-In type.

Go add account linking to your Actions!

To summarize, account linking is a great way to provide personalized Actions, which in turn provide a much better user experience. The new Google Sign-in flow significantly decreases the complexity of linking accounts for your Actions, and you can now reap the benefits of account linking with pretty minimal effort when you use Google Sign-In.

Check our new account linking docs and try our new Google Sign-In sample,

and let us know what you think about the new solution and the new docs in our G+ community. If you have technical questions about implementing account linking, don’t hesitate to post them on Stack Overflow.

Have fun personalizing your Actions with account linking!