Authenticating users with Actions on Google

Actions on Google is a pretty fascinating platform when it comes to the creation of conversational tools. So far myself I’ve been able to create a couple of small tools that could have the potential to help users out in one way or another. But they always been missing that one important thing, personalisation. Having access to some form of identification for the user not only allows us to create a more personalised experience, but also opens up numerous possibilities for the kind of conversational tools that we can create. in this article I want to dive into Account Linking that allows us to do just that.

What is Account Linking?

Account Linking is a component of Actions on Google that allows users to connect their Google accounts to the service that our conversational tool has been built for. We’d want to do this for numerous reasons, first of all our application might require us to fetch existing preferences for our users account that our conversational tool can utilise — or we may need to log the user into their account before they can use the service. Account Linking gives our tool more context, more personalisation and much more functionality.

When prompted to connect their account, the user will be shown the standard Google account selection dialog — if the Conversation is being used on a device with a screen then this will automatically pop-up, users of the Google Home will need to do this using the Google Home app.

At this point, once the user has selected an account you will be able to check whether or not the users account is currently associated with your service. If it turns out that this isn’t the case then the user will be shown a dialog that will allow them to create an account there an then, allowing them to continue using your service within the conversation, this is known as Seamless Account Linking.

In-order to use Account Linking with Actions on Google, the server you are making requests to will need to be using the OAuth 2.0 flow — Actions supports both implicit and Authorisation code flows.

Prompting Account Linking

When your conversation requires sign-in by the user, there are two different points in the conversation which you can request this action:

Within the Dialog Flow console we can request that our Default Welcome Intent requires sign in from the user. This means that when our conversation begins the user will be prompted to connect their account right away — they will not be able to continue with the conversation unless this action is completed.

This approach would be recommended in situations where the service being used for the conversation cannot function without access to the users account. However, in situations where you don’t need immediate access to the users account (for example, maybe only certain events require a user account to perform them) it would make sense to put off user authorisation until it is required.

We can do this by requesting the actions.intent.SIGN_IN intent at any point during our conversation using the actions-on-google SDK like so:

function signIn(app) {
  app.askForSignIn();
}

This process will launch exactly the same flow as if we were requesting sign-in when the conversation starts. When the sign in flow completes we will receive a callback where we can check the result of the sign-in process and act accordingly:

function signInHandler(app) {
  if (app.getSignInStatus() === app.SignInStatus.OK) {
    let accessToken = app.getUser().accessToken;
  } else {
    app.tell('You need to sign-in before using the app.');
  }
}

Setting up Account Linking for our Conversation

Within the Actions on Google console we can enabled account linking for our tool by supplying a few bits of required information. If we head on over to console.actions.google.com and head to our project Overview, we should be able to see a screen similar to below:

You’ll notice the last item, Account Linking, selecting this will take us on over to the screen to input the required Account Linking information.

When trying this out I used the Buffer API which uses the Authorisation Code approach, you’ll need to select the authorisation mode before filling out the rest of the form:

Next, you’ll need to fill out the credentials used for the OAuth 2.0 flow. This consists of the Client ID, Client Secret, Authorsation URL and Token URL. Actions on Google will use this information to communicate with your service and perform the authorisation flow.

If you want to request any extra scopes for interactions with your service, under the Configure your client section you can provide scopes to be requested at the point of authorization:

The final step allows you to enable the ability for users to create an account with your service during the account linking flow. This isn’t required, but if not enabled then you will be restricting some parts (or all) of your conversational tool to existing users only.

At this point you have provided the required information to allow users to connect their accounts to your conversational tool using the Actions on Google console.

Testing Account linking

You can test account linking by opening up the Actions on Google simulator from within the console and invoke the Intent that requires a connected user. When you invoke this Intent you will be prompted to connect an account:

At this point because we are using the simulator, we need to head on over to the Debug tab and you’ll notice that there is an Authorisation URL which we can copy + paste into our browser to perform Account Linking. Once completed, we will be able to continue using our conversation tool with a linked account. This isn’t the smoothest testing process currently, but it works!

Conclusion

Account Linking only requires us to add a few bits of information in order to make our conversations more personalised and functional. I’ve experimented with linking accounts in a sample app of mine (source coming soon) and I’m looking forward to playing around with it some more! I’d love to hear how you’re using it or any questions you may have 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *