Troubleshoot single sign-on (SSO)

This error typically indicates that you're using a version of Google Workspace that doesn't support SSO (such as the legacy free edition of G Suite). All current Workspace editions support SSO via a third-party Identity provider (IdP). 

If you're using a Google Workspace edition that supports SSO, try these other solutions:

• Verify that your IdP's SSO configuration is using the correct Google Workspace domain name.
• If you get this error after setting up SSO profiles, your IdP may be configured to send the SAML assertion to the legacy SSO profile endpoint. If your IdP has the legacy SSO endpoint hard-coded, please do the following:
  1. Set up legacy SSO.
  2. Ask your IdP vendor to update their Google integration.

This error indicates you haven't set up SSO correctly in the Google Admin console. Review the following steps to correct the situation:

1. In the Admin console, go to SecuritySet up single sign-on (SSO) with a third party IdP, and check Set up SSO with third-party identity provider.
2. Provide URLs for your organization's sign-in page, sign-out page, and change password page in the corresponding fields.
3. Choose and upload a valid verification certificate file.
4. Click Save, wait a few minutes for your changes to take effect, and test your integration again.

With iOS applications, when the SSO Sign-in page URL starts with "google." (or some variation), the Google iOS app is redirected to Safari. This causes the SSO process to fail. The full list of forbidden prefixes is:

• googl.
• google.
• www.googl.
• www.google.

You'll need to change any SSO Sign-in page URLs that have these prefixes.

This error message indicates that your Identity Provider is not providing Google with a valid SAML Response of some kind. This problem is almost certainly due to a configuration issue in the Identity Provider.

• Check your Identity Provider logs and make sure that there is nothing preventing it from correctly returning a SAML Response.
• Ensure that your Identity Provider is not sending Google Workspace an encrypted SAML Response. Google Workspace only accepts SAML Responses that are unencrypted. In particular, please note that Microsoft's Active Directory Federation Services 2.0 often sends encrypted SAML Responses in default configurations.

The SAML 2.0 specification requires that Identity Providers retrieve and send back a RelayState URL parameter from Resource Providers (such as Google Workspace). Google Workspace provides this value to the Identity Provider in the SAML Request, and the exact contents can differ in every login. For authentication to complete successfully, the exact RelayState must be returned in the SAML Response. According to the SAML standard specification, your Identity Provider should not modify the RelayState during the login flow.

• Diagnose this issue further by capturing HTTP headers during a login attempt. Extract the RelayState from the HTTP headers with both the SAML Request and Response, and make sure that the RelayState values in the Request and Response match.
• Most commercially available or open-source SSO Identity Providers transmit the RelayState seamlessly by default. For optimum security and reliability, we recommend that you use one of these existing solutions and we cannot offer support for your own custom SSO software.

This error indicates that the destination, audience or recipient elements in the SAML assertion contained invalid information or were empty. All elements must be included in the SAML assertion. Check the following tables in SSO assertion requirements for descriptions and examples for each element:

• Use elements and attributes—SSO profiles
• Use elements and attributes—legacy SSO profile

This error usually indicates that the SAML Response from your Identity Provider lacks a readable Recipient value (or that the Recipient value is incorrect). The Recipient value is an important component of the SAML Response.

1. Diagnose this issue further by capturing HTTP headers during a login attempt.
2. Extract the SAML Request and Response from the HTTP headers.
3. Ensure that the Recipient value in the SAML Response exists and that it matches the value in the SAML Request.

Note: This error message may also appear as "This service cannot be accessed because your login request contained invalid recipient information. Please log in and try again."

This error indicates a problem with the certificates you're using to sign the authentication flow. It usually means the private key used to sign the SAML Response doesn't match the public key certificate that Google Workspace has on file.

It can also occur if your SAML Response doesn't contain a viable Google Accounts username. Google Workspace parses the SAML Response for an XML element called a NameID, and expects this element to contain a Google Workspace username or a full Google Workspace email address.

• Ensure that you've uploaded a valid certificate to Google Workspace, and if necessary replace the certificate. In the Google Admin console, go to SecuritySet up single sign-on (SSO) with a third party IdP and click Replace certificate.
• If you're using a full email address in your NameID element (you must be if you are using SSO with a multidomain Apps environment), ensure that the Format attribute of the NameID element specifies that a full email address is to be used, as in the following example: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress".
• Ensure that you're populating the NameID element with a valid username or email address. To be certain, extract the SAML Response you're sending to Google Workspace, and check the value of the NameID element.
• NameID is case-sensitive: ensure that the SAML Response is populating NameID with a value that matches the case of the Google Workspace username or email address. 
• If your Identity Provider is encrypting your SAML Assertion, disable encryption.
• Ensure that the SAML Response doesn't include any non-standard ASCII characters. This issue most commonly occurs in the DisplayName, GivenName, and Surname attributes in the AttributeStatement, for example:
  • <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
    <AttributeValue>Blüte, Eva</AttributeValue> </Attribute>
  • <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
    <AttributeValue>Blüte</AttributeValue> </Attribute>

For more information on how to format the NameID element, see SSO assertion requirements.

For security reasons, the SSO login flow must complete within a certain timeframe, or authentication fails. If the clock on your Identity Provider is incorrect, most or all login attempts will appear to be out of the acceptable timeframe, and authentication will fail with the above error message.

• Check the clock on your Identity Provider's server. This error is almost always caused by the Identity Provider's clock being incorrect, which adds incorrect timestamps to the SAML Response.
• Resync the Identity Provider server clock with a reliable internet time server. When this issue suddenly occurs in a production environment, it is typically because the last time sync failed, causing the server time to become inaccurate. Repeating the time sync (possibly with a more reliable time server) will quickly remedy this issue.
• This issue can also occur if you are resending SAML from a previous login attempt. Examining your SAML Request and Response (obtained from HTTP header logs captured during a login attempt) can help you debug this further.

For security reasons, the SSO login flow must complete within a certain timeframe, or authentication fails. If the clock on your Identity Provider is incorrect, most or all login attempts will appear to be out of the acceptable timeframe, and authentication will fail with the above error message.

• Check the clock on your Identity Provider's server. This error is almost always caused by the Identity Provider's clock being incorrect, which adds incorrect timestamps to the SAML Response.
• Resync the Identity Provider server clock with a reliable internet time server. When this issue suddenly occurs in a production environment, it is typically because the last time sync failed, causing the server time to become inaccurate. Repeating the time sync (possibly with a more reliable time server) will quickly remedy this issue.