What Google sign-in is
Sign in with Google lets people create an account and sign in with the Google Account they already have: a button and One Tap on the web, Credential Manager on Android, and Google's sign-in SDK on iOS. The app receives an ID token, signed by Google, that says who the person is.
Google Workspace accounts are Google Accounts too, managed by a company's administrators, so the same kind of sign-in can let your staff into the backoffice. Those two uses are why Google is one of the social sign-in options of our authentication module and one of the staff sign-in options of the backoffice.
What it does in your platform
Authentication
Adds the Google button and One Tap to your sign-up and sign-in screens. The module verifies Google's ID token, opens or creates the customer's account, and keeps its own sessions, trusted devices and the second factor on payments.
Admin backoffice
Signs your staff in with their Google Workspace accounts, from your company's domain only. Through a SAML app in your Workspace admin console, their Google groups can arrive with the sign-in and decide each person's role.
How the connection works
Customer sign-in uses Google's own SDKs on each platform, and our Flutter apps use the google_sign_in plugin from Google's Flutter team. The platform verifies every token on the server, and Google's Cross-Account Protection sends it signed security events.
A customer taps Google
On Android, Credential Manager offers their Google accounts; on the web, One Tap or the button; on iPhone, Google's sign-in SDK.
Google returns a token
The app receives an ID token, a JSON web token signed by Google, with the person's Google account ID, email and name, and passes it to the platform.
The platform verifies
The module checks the signature against Google's public keys, that the token was issued for your app and that it has not expired, then opens a session.
Google flags trouble
If Google later disables the account for hijacking, or revokes its sessions, Cross-Account Protection sends a signed security event, so the platform can sign the customer out.
Next to other providers
Google sits next to Sign in with Apple and Microsoft on the same sign-in screen, and next to passkeys and one-time codes. Each method opens the same kind of customer account in the platform, with the same sessions and checks.
On the staff side, Google Workspace is one of the backoffice's sign-in options next to Okta, Microsoft Entra ID and Keycloak. Moving staff from one to another later is a configuration change, and the audit log keeps every past action.
When Google fits best
A strong fit when
- Many of your customers use Android phones or Gmail, and you want a one-tap sign-up.
- Your company runs on Google Workspace and wants staff to use the same accounts for the backoffice.
- You want Google's security events, such as a hijacked account, to reach your platform.
Also worth a look
- Sign in with Apple next to it, especially when your iOS app offers Google sign-in.
- Okta or Microsoft Entra ID for staff, when your directory lives there.
How we get you live
The Google project
We set up the Google Auth Platform in your Google Cloud project: your app's name, support email and an OAuth client for the web, Android and iOS, and we take the app through Google's verification.
Workspace for staff
With your Workspace super administrator, we add the backoffice as a custom SAML app, map your groups and turn it on for the teams that need it.
The keys
OAuth client secrets go into your platform's secrets and nowhere else, and we register the platform's endpoint for Google's security events.
A full test run
We test a customer sign-up on each platform, a staff sign-in with group roles and a test security event before launch.
