How to rotate certificates
If you upload two certificates to a SAML Single Sign-On (SSO) profile, Google can use either certificate to validate a SAML response from your IdP. This allows you to safely rotate an expiring certificate on the IdP side. Follow these steps at least 24 hours before a certificate is due to expire:
- Create a new certificate on the IdP.
- Upload the certificate as the second certificate to Admin console. For instructions see Create a SAML profile .
- Wait 24 hours to allow for Google user accounts to update with the new certificate.
- Configure the IdP to use the new certificate in place of the expiring one.
- (Optional) Once users have confirmed they are able to sign in, remove the old certificate from Admin console. You can then upload a new certificate in the future as needed.
Use Autofill email to simplify SSO sign-ins
To help your users sign in, turn on Autofill emailwhen creating or updating an Inbound SAML Single Sign-On (SSO) profile.
Autofill email automatically fills in the email address field on your third-party identity provider's (IdP) sign-in page. Therefore, users only have to enter their password. You can turn on Autofill emailwhen you create a new Inbound SAML SSO profile or update an existing one.
Autofill email uses a login hintparameter to securely send your users' email addresses to your IdP. This parameter is a common feature that many third-party IdPs support for IdP-initiated sign-ins.
The login hint's parameter isn't standardized, so different IdPs use different variations, such as:
- login_hint: (supported by IdPs like Microsoft Entra)
- LoginHint: (supported by IdPs like Okta)
Because of these variations, you'll need to confirm which format your IdP supports and choose the corresponding setting in the Google Admin console.
Options to turn on Autofill email
- Sign in with an administrator account to the Google Admin console.
If you aren’t using an administrator account, you can’t access the Admin console.
- Go to Menu Security > Authentication > SSO with third party IdP .
Requires having the Security settings administrator privilege.
- In the Third-party SSO profilessection, click Add SAML profile.
- For SAML SSO profile, enter a profile name.
- For Autofill email, select the option that matches your IdP's supported login hint format.
- In the IdP detailssection, complete the following steps:
- Enter the IDP entity ID, Sign-in page URL, and Sign-out page URLthat you got from your IdP.
- For Change password URL, enter a change password URL for your IdP.
Users will go to this URL to reset their passwords.
- Click Saveand continue creating the profile.
- Sign in with an administrator account to the Google Admin console.
If you aren’t using an administrator account, you can’t access the Admin console.
- Go to Menu Security > Authentication > SSO with third party IdP .
Requires having the Security settings administrator privilege.
- In the Third-party SSO profilessection, click the profile that you want to update.
- Click SP details.
- For Autofill email, select the option that matches your IdP's supported login hint format.
- Click Save.
Manage domain-specific service URLS
The Domain-specific service URLssetting lets you control what happens when users sign in using service URLs such as https://mail.google.com/a/example.com.
- Sign in with an administrator account to the Google Admin console.
If you aren’t using an administrator account, you can’t access the Admin console.
- Go to Menu Security > Authentication > SSO with third party IdP .
Requires having the Security settings administrator privilege.
- Click Domain-specific Service URLsto open the settings.
There are two options:
- Redirect users to the third-party IdP. Choose this option to always route these users to the third-party IdP that you select in the SSO profile drop-down list. This can be the SSO profile for your organization, or another third-party profile (if you’ve added one).
Important:If you have organizational units or groups that are not using SSO, don’t choose this setting. Your non-SSO users will be automatically routed to the IdP and won’t be able to sign in.
- Require users to enter their username on Google’s sign-in page. With this option, users entering domain-specific URLs are first sent to the Google sign-in page. If they are SSO users, they’re redirected to the IdP sign-in page.
Network Mapping results
Network masks are IP addresses that are represented using Classless Inter-Domain Routing (CIDR) notation. The CIDR specifies how many bits of the IP address are included. The SSO profile for your organization can use network masks to determine which IP addresses or ranges of IP addresses to present with the SSO service.
Note: For the network masks settings, only domain-specific service URLs, for example service.google.com/a/example.com, currently redirect to the SSO sign-in page.
It is important for each network mask to use the correct format. In the following IPv6 example, the slash (/) and the number after it represent the CIDR. The last 96 bits are not taken into consideration, and all of the IP addresses in that network range are affected.
- 2001:db8::/32
In this IPv4 example, the last 8 bits (the zero) are not be taken into consideration, and all of the IP addresses that were in the range of 64.233.187.0 through 64.233.187.255 would be affected.
- 64.233.187.0/24
In domains without a network mask, you must add users who are not super administrators to the identity provider (IdP).
SSO user experience when visiting Google service URLsThe following table shows the user experience for direct visits to Google service URLs, with and without a network mask:
/a/ your_domain.com*
( within network mask)
/a/ your_domain.com
( outside network
mask)
o/oauth2/v2/auth?login_hint=
xxxxx@example.com
Users who access Google's OAuth 2.0 endpoint using the login_hintURL parameter are redirected to the SSO sign-in page.
* Not all services support this URL pattern. Examples of services that do are Gmail and Drive.
- Your domain has SSO with a third-party IdP.
- Your domain has a network mask.
- A user signed in through the third-party IdP (see the table in “SSO user/network mapping matrix”).
- The user session reaches its maximum allowed duration as specified in the Google session control Admin console setting.
- The admin modified the user account by changing the password or requiring the user to change the password at their next sign-in (either through the Admin console or using the Admin SDK).
User experience
If the user initiated the session on a third-party IdP, the session is cleared and the user is redirected to the Google Sign-in page.
Because the user initiated their Google session on a third-party IdP, they might not understand why they need to sign in to Google to regain access to their account. Users might get redirected to a Google Sign-in page even when they try to navigate to other Google URLs.
If you’re planning some maintenance that includes terminating active user sessions and want to avoid user confusion, tell your users to logout from their sessions and stay logged out until the maintenance is complete.
User recovery
When a user sees the Google Sign-in page because their active session was terminated, they can regain access to their account by doing one of the following:
- If the user sees the message “If you’ve reached this page in error, click here to sign out and try to sign in again,” they can click the link in the message.
- If the user doesn’t see that message or link, they sign out and sign in again by going to https://accounts.google.com/logout .
- The user can clear their browser cookies.
Once they use any one of the recovery methods, their Google session is fully terminated and they can sign in.
Set up 2-Step Verification with SSO
- Sign in with an administrator account to the Google Admin console.
If you aren’t using an administrator account, you can’t access the Admin console.
- Go to Menu Security > Authentication > Login challenges .
Requires having the User security management administrator privilege.
- On the left, select the organizational unit where you want to set the policy.
For all users, select the top-level organizational unit. Initially, organizational units inherit the settings of its parent.
- Click Post-SSO verification.
- Choose settings according to how you use SSO profiles in your organization. You can apply a setting for users who use the legacy SSO profile and for users who sign in using other SSO profiles .
- On the bottom right, click Save.
Google creates an entry in the Admin audit log to indicate any policy change.
The default post-SSO verification setting depends on SSO user type:
- For users signing in using the legacy SSO profile, the default setting is to bypassadditional login challenges and 2SV.
- For users signing in using SSO profiles, the default setting is to applyadditional login challenges and 2SV.
See also
Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.
