Google One Tap

This page describes the setup required by a client to enable sign-in and sign-up using Google One Tap.

JavaScript API

The client is required to use Google's JavaScript API for One Tap instead of the HTML API. One of the reasons being that the JavaScript API is much more configurable than the HTML API. There are also fundamental differences in the flow, for example, the HTML API will make a direct call from the Google servers to our authentication server and this requires CSRF validation which is not required when using the JavaScript API.

Flow

1. You can control when and where to show and hide the One-tap prompt. Refer to the Google's JavaScript API for One-tap for more information on how to do it.
2. Once the prompt is shown to the user, and the user clicks on his account, the JS library will make a call to Google's backend to verify the user preliminarily.
3. The One-tap JS expects you to pass a custom callback that will be invoked on successful verification of the user in the above step. On successful verification, the callback will be invoked with CredentialResponse as the argument.
4. The CredentialResponse has a key named credential. The value of this credential is required to verify the user with Bridgekeeper and handle the subsequent session management flows that Bridgekeeper provides.
5. So inside the callback,
   1. Firstly, a POST call should be made to /api/auth/v1/login/google-one-tap with the body as,

      {
        "token": "<value of CredentialResponse.credential>",
        "redirect-url": "https://yourwebsite.com"
      }

      The token is required while the redirect-url is optional.
   2. On successful authentication of the user, Bridgeekeeper will send a response, with 200 as status code and a JSON body having the user's details. And if there is a valid redirect-url passed in the body, it will respond with a 302 and the Location header as the redirect-url.
   3. Importantly, Bridgekeeper will set the qt-auth cookie which will be used for subsequent session management flows.
   4. At this point, the client can start using the User object from the response and perform any custom actions like storing the User object in the Redux store, disabling the One-tap prompt and so on.
6. If the user does not already exist in Bridgekeeper, then a new user and a session is created. Otherwise, a new session is created for the existing user.
7. Since the qt-auth cookie is now set. Bridgekeeper APIs can be used for, say, session validation using /api/auth/v1/users/me, logging out using /api/auth/v1/logout and so on.