About SSO

Single sign-on (SSO) allows users to sign in to many enterprise cloud applications using a single set of credentials. Workspace (and Google Cloud Platform) support SSO from third-party identity providers (IdPs) using either SAML or OIDC protocols.

To use SSO, you configure SSO profiles, then assign them to user groups or organizational units. This allows support for multiple IdPs and for testing SSO configurations. This is the recommended system for SSO. Our older Legacy SSO profile for organizations is also available (for SAML only).

SSO is also available on Chrome devices. For details, go to Configure SAML single sign-on for Chrome Devices.

Additional verification after SSO

When SSO is set up,  users who sign in to their third-party IdP can access Google apps without additional verification, with these exceptions:

• Even if they've already signed in to their IdP, as an extra security measure, Google will sometimes ask them to verify their identity. For more information, (and details on how to disable this verification if necessary), go to Understanding SAML secure sign-in.
• You can set up additional two-step verification for users who access Google services. Two-step verification is normally bypassed when SSO is turned on. For more information, go to Enable challenges with SSO.

Understanding partner-operated SAML-based SSO

Figure 1 illustrates the process by which a user signs in to a Google application, such as Gmail, through a SAML-based SSO service that is partner operated. The numbered list that follows the image details each step.

Important: Before this process takes place, the partner must provide Google with the URL for its SSO service as well as the public key that Google should use to verify SAML responses.

Figure 1: This shows the process of signing in to Google using a SAML-based SSO service. 

This image illustrates the following steps.

1. The user attempts to reach a hosted Google application, such as Gmail, Google Calendar, or another Google service.
2. Google generates a SAML authentication request, which is encoded and embedded into the URL for the partner's SSO service. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is an opaque identifier that is passed back without any modification or inspection.
3. Google sends a redirect to the user's browser. The redirect URL includes the encoded SAML authentication request that should be submitted to the partner's SSO service.
4. The browser redirects to the SSO URL.
5. The partner decodes the SAML request and extracts the URL for both Google's ACS (Assertion Consumer Service) and the user's destination URL (RelayState parameter). 
6. The partner then authenticates the user. Partners can authenticate users by either asking for valid login credentials or by checking for valid session cookies.
7. The partner generates a SAML response that contains the authenticated user's username. In accordance with the SAML v2.0 specification, this response is digitally signed with the partner's public and private DSA/RSA keys.
8. The partner encodes the SAML response and the RelayState parameter and returns that information to the user's browser. The partner provides a mechanism so that the browser can forward that information to Google's ACS. For example, the partner could embed the SAML response and destination URL in a form and provide a button that the user can click to submit the form to Google. The partner could also include JavaScript on the page that submits the form to Google.
9. The browser sends a response to the ACS URL. Google's ACS verifies the SAML response using the partner's public key. If the response is successfully verified, ACS redirects the user to the destination URL. 
10. The user is signed in to the Google app.

Synchronizing user accounts between your IdP and Google

To simplify user lifecycle management, most organizations using SSO also synchronize their user directory from the IdP to Google. With sync in place, new (or deleted) users on the IdP side are automatically added or deleted as Workspace users. Google’s Directory Sync supports Active Directory and Entra ID. Most IdPs support sync to Google. See your IdP's documentation for setup instructions. 

SSO and Secure LDAP

Secure LDAP requires a Google password and is incompatible with SSO.