Google SSO: How It Works and 4 Tips for Success

What Is Google SSO?

All Google services, including services like Google Cloud and YouTube, use the Google Sign-In service by default to authenticate users. It works as follows:

1. When a user attempts to access a Google service that requires authentication, they are redirected to accounts.google.com.
2. The user is presented with a Google sign-in screen, asking them to enter an email address. 
3. Depending on the provided email address’s domain, user accounts are looked up in the consumer-account directory for Gmail. If a domain matches the primary or secondary (or alias) domain, the service searches for a Google Workspace or Cloud Identity account.
4. The user is asked to enter their password.
5. If the password is correct, the user is redirected back to the specific page or resource they were trying to access.

Google also provides a single-sign on (SSO) feature that lets you authenticate users via external identity providers (IdP). For example, you can allow users in an organization to sign into their Google-based email with the same username and password they use to access the corporate network.

In this article:

How Does Google SSO Work?

Google offers SSO for Cloud Identity and Google Workspace accounts. After enabling SSO, users no longer need to enter a password when attempting to access Google services. Instead, the SSO functionality redirects users to an external identity provider (IdP) for authentication. It facilitates a better user experience, enabling using existing credentials to authenticate.

Works with existing IdP

Administrators employ SSO to continue using an existing IdP without having to synchronize passwords to a Google Workspace or Cloud Identity. Users can use SSO only if they have a Google Workspace or Cloud Identity account with a corresponding identity recorded in an external IdP. 

Supports Security Assertion Markup Language (SAML) 2.0

Google Workspace and Cloud Identity support SAML 2.0 for SSO. The SAML open standard helps secure authentication and authorization data exchanges between IdPs and service providers. When using SSO for Google Workspace or Cloud Identity, Google is the SAML service provider, and the external IdP is the SAML IdP.

Implements SAML 2.0 HTTP POST binding

This binding determines how the SAML IdP and SAML service provider can exchange authentication information. The diagram below illustrates how this process works when using SSO to access the Google Cloud console.

1. The user points their browser to the Google Cloud console (or another Google resource).

2. The console redirects the browser to Google Sign-In.

3. Google Sign-In displays a sign-in page that prompts the user to enter their email address.

4. The user enters their email address and submits the form.

5. Google Sign-In searches for the Cloud Identity or Google Workspace account associated with the specified email address.

6. Google Sign-In redirects the user’s browser to the configured external IdP’s URL. Before it issues this redirect, it adds two parameters to the URL (for more details on these parameters, see the SAML specification):
   • The RelayState parameter – containing an identifier the external IdP must pass back later. 
   • The SAMLRequest parameter – containing the SAML authentication request, a deflated XML document, URL-encoded, and base64-encoded.

7. The external IdP returns a unique HTML page that causes the user’s browser to send an HTTP POST request immediately to the ACS URL. The Google Assertion Consumer Service, or ACS URL, tells an IdP where to redirect an authenticated user after sign-in. A Google ACS URL uses this format: https://www.google.com/a/domain.com/acs

8. The browser posts a SAML assertion to the Google ACS URL.

9. The Google ACS URL verifies the SAML assertion’s digital signature. This check helps ensure the assertion came from a trusted external IdP and was not tampered with. If the signature is valid, the ACS endpoint analyzes the assertion’s contents, reading the NameID attribute and verifying its audience information.

10. The ACS endpoint searches for the user account by trying to match the SAML assertion’s NameID to the user’s primary email address. 

11. The ACS endpoint starts a session. It uses the information encoded in the RelayState parameter to determine the URL of the resource intended for access, redirecting the user to the Google Cloud console.

Related content: Read our guide to Single Sign on Solutions

Google SSO: 4 Tips for Success

1. Avoid Using Non-Essential SAML Attributes

When a user authenticates with Google SSO, the first step is to identify the G Suite or Cloud Identity user account. This is done by passing a NameID value – a SAML parameter that identifies the “subject” of the SAML session who needs to be authenticated.

In addition to NameID, SAML assertions can include multiple other attributes, like username, last name, and group membership. However, these additional attributes are not considered by Google SSO during authentication, because Cloud Identity or G Suite user accounts are exclusive sources for user information.

To reduce the size of your SAML assertions and improve performance, you can configure the IdP not to include attributes that aren’t required for Google Sign-in.

2. Use google.com as the Issuer

Google sign-in sessions are not limited to one tool or domain. Rather, once a session is established, it is valid for all G Suite services to which the user has access. These services may include Google Cloud, YouTube, Google Ads, and Google Search.

The session’s global nature is reflected in SAML protocol exchanges. By default, google.com is the issuer of SAML requests (i.e., the Issuer element) and SAML assertions use google.com as the destination (the Audience element of the SAML response).

For users with multiple Cloud Identity/Google Workspace accounts, and thus multiple domains, it is possible to set domain-specific issuers to allow the IdP to distinguish between logins that belong to different domains. This works as follows:

• Select Use a domain-specific issuer when configuring SSO in Cloud Identity/Google Workspace. 
• SAML requests will then use google.com/a/DOMAIN as the Issuer (with DOMAIN as the default domain for your Cloud Identity /Google Workspace account).
• Google will expect google.com/a/DOMAIN as the Audience. 

3. Align the Length of Google Sessions and IdP Sessions

After the user completes the SSO process and establishes a session, Google’s sign-in session will remain active for a specified period. After this time, or if the user logs out, Google will prompt the user to repeat the SSO process to re-authenticate.

By default, the duration of a session for Google services is 14 days. If a user has a Google Workspace Business or Cloud Identity Premium or license, it is possible to change the duration of the default session (for example, shorten it to 12 hours). This session duration applies to the Google Cloud console, the Google Cloud CLI, and other API clients. All Cloud Identity and G Suite account types can set a custom session length in Google Cloud.

Keep in mind that most external IdPs maintain sessions for authenticated users. If the IdP’s session is longer than Google’s session length, automatic re-authentication may occur. This means redirecting the user to the IdP, but the user will not have to re-enter their credentials. To ensure all users are required to re-enter their credentials, ensure that IdP session limit is always shorter than Google session limit.

4. Disable Single Sign-on for Super-Admin Users

A Google Workspace super admin account has a broad set of administrative capabilities across all Google services, including Google Drive, Google Docs, and Google Cloud services. 

SSO is optional for super-admin users. They can use single sign-on when logging in via the IdP, but can also log in with a username and password.

If you don’t want to use IdP-initiated SSO for super-admins, take the following steps to reduce security risk:

• Add a designated unit for super-admins only.
• Assign the SSO profile to the unit for which you want to disable single sign-on.

Otherwise, if you want to use IdP-initiated SSO, you must enforce SSO post-authentication for the super admin user.

Cloud-Based SSO with Frontegg

Once you integrate Frontegg’s self-served user management solution, your customers can configure their SSO completely on their own with just a few lines of code. The single sign-on can be integrated with IDPs with commonly-used protocols like OIDC and SAML. Yes, you can implement social login SSOs as well. 

The front end has been taken care of as well. You can leverage all of Frontegg’s SSO components and personalize your SaaS offering with a customizable login box. This embeddable box reduces in-app friction and allows users to authenticate smoothly and gain quick access to the app. A true end-to-end SSO solution.

Learn more about Frontegg SSO