Google Identity Platform for Building a Custom User Management Application

Google has two products for identity.

1. Google Cloud Identity — also known as workspace identity or simply your gmail account
2. Google Identity Platform — a part of Google Cloud Platform for new applications.

This blog describes the difference between the two nicely Google Cloud Identity vs Identity Platform.

You would normally use gcp google cloud platform as a social login in your application. Whereas you will use Google Identity Platform for building a custom user management application or securing your services (user level security).
The question is why would you use Identity Platform in your custom user management application and what are its benefits. One aspect of the user management application is authentication — securely authenticate a user, enforce password policy, ensure passwords are securely stored, multi-factor authentication, link multiple accounts. The Google Identity Platform provides all this and more. It is an enterprise class (or Google Class) authentication service. This is a big deal. Once the authentication is available as a service, you can build your own database of users for storing other user attributes such as address, multiple phones in a database. Of Course you will pick a secure database (such as Cloud SQL) and add custom encryption to it. Firebase is one such application.

In this blog our focus is to use Google Identity Platform for building a custom user management application i.e. how to integrate in a new application. We will also cover how to use it for authorizing API access.

For those you are familiar with AWS, Google Identity Platform is equivalent to AWS Cognito i.e. two are used in the same way.

Let us say your problem is to build a large scale user management application for a B2B or B2C application. One option is that you build everything including password management/policy, multi-factor authentication (MFA), SAML, OIDC, social login, audit trail, manage token lifecycle etc. It is lots of work and responsibility to develop a secure, enterprise grade and compliant authentication service. If you use Google Identity Platform, you can offload the heavy lifting to it.

When you use Google Identity Platform in your user management application, the architecture looks as follows:

When the new user API of the User Management (UM) is called, it will work with the Identity Platform as follows.

1. User Management (UM) application will create a new user in the Identity Platform using its API and by passing email, password and phone (for MFA).
2. The Identity Platform API will return a unique-id (identity-id) of the created user.
3. UM will save other attributes of the user in the database and link the newly created record with the Identity Platform unique-id.

API reference for creating a new user sign up.

Cloud Identity Platform provides multiple ways of authenticating a user depending on your application and configuration. The most common is email and password. Once a user is successfully authenticated by email/password, the API returns idToken, refreshToken and token validity duration (expiresIn) and a few more attributes. If MFA is enabled, the API call also returns MFA info (such as phone numbers).

API reference for authenticating a user with password is here.

If the two factor authentication is enabled, the returned idToken is not valid (can’t be used in authorization). In case of MFA, the UM application invokes API to send the code to the second factor such as a phone number. The application may do it transparently or after confirming with the user. The verification API returns “sessionInfo”.

API to send the verification code to the user.

The application then prompts the user to input verification code sent to the second factor. The entered code and sessionInfo are sent to the Cloud Identity Platform using for example “signInWithPhoneNumber. If it succeeds then the idToken becomes a valid token for authorization.

Sign in with the phone number and session info are provided here.

The idToken returned by authentication flow is used in the API calls. Typically, your API requires user info associated with the token. Therefore, calling the user info API implicitly validates the id token.

Use get account info to implicitly validate the idToken and retrieve user info

Of course, due to performance reason, you will likely cache the results of the validation in a distributed cache (for a clustering environment) and revalidate after a few minutes.

In addition to the above APIs, Cloud Identity Platform provides several APIs. Some important APIs are listed below.

1. Sending verification email.
2. Confirm email verification code.
3. Send a reset password email.
4. Change password.
5. Update user profile.
6. Disable or delete users.
7. Custom IDP support.
8. SAML support.

Cloud identity platform provides several services. Building these services in an application is an expensive and security prone undertaking. To ice the cake, Cloud Identity Platform is free upto 49,999 users (at the time of writing this blog).