This post is about a really specific issue that you might not run into unless you are extremely unlucky.
Integrating systems with Google Workspace for the purposes of enabling Single Sign On is a very common thing, mainly because of how simple it is and the fact it doesn't incur much cost or maintenance once it's in place. Many companies integrate their Slack workspaces with Google to enable their employees to SSO into their Slack accounts, which improves the user experience and reduces administration overhead.
Despite its allure, companies eventually outgrow the capabilities of Google as an IdP and many migrate to more powerful identity providers (e.g. Okta, Ping Identity, ...). Google Workspace supports using third-party IdPs to allow users to SSO into their Google account, and the configuration is quite straightforward.
A very common – and rather wise – strategy is to integrate Google Workspace with the third-party IdP, but leave the systems that have been integrated with Google as they are and slowly move them to the new identity provider. This allows companies to integrate Google without distrusting access to these systems depending on it; but also it ensures that your team won't be overloaded trying to integrate all dependant systems at the same time. If we take Slack as an example, the new login flow will look like this (let's assume the company is using Okta):
- User goes to the Slack login page.
- They click on Login using Google.
- If they are logged into Google, they are logged into Slack.
- If they don't have an active session in Google, they are redirected to Okta for a session check.
- If they have an active Okta session, they are logged into Google, and then back into Slack.
- If they don't have an active Okta session, they will be asked to log in into Okta. Once logged in, they will be logged into Google, then into Slack.
When rolling out the Google integration, companies use Organization Units on Google Workspace to enable the new SSO experience in smaller sections to avoid major disruptions for the entire workforce. This means only those in the OUs where the SSO integration was enabled will be subjected to the flow described above. Everyone else will be able to log in normally (no redirections to the third-party IdP). Well, at least this what you would expect as an engineer, but there is a small setting that can ruin your day and cause havoc if you don't configure it correctly.
When configuring the integration with the third-party IdP, you need to configure Domain-specific service URLs (see picture below). This basically controls if users will be automatically redirect to the IdP when they visit any of the Google services (e.g. Gmail, Meet, ...) without a valid session.
If you leave this setting set to "Automatically redirect users to the third-party IdP", all of your Slack users (including those who are in Google OUs where SSO isn't enabled) will be redirected to your IdP when they try to log in to Slack. This is a terrible thing that can cause serious problems, as a considerable number of users might be blocked from logging to Slack until they have SSO enabled for their OUs. Instead, set this policy to "Require users to enter their username on Google's Sign-in page first", at least until SSO is enabled for all users in your Google Workspace.
It's such a small configuration, but it has the potential to give you a headache for an entire week if you don't configure it correctly. Now you know and, hopefully, you won't fall into this mistake.