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:
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:
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.
Related content: Read our guide to Single Sign on Solutions
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.
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:
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.
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:
Otherwise, if you want to use IdP-initiated SSO, you must enforce SSO post-authentication for the super admin user.
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
