Many organizations have user accounts in a Google Workspace (formerly known as G Suite) and would prefer to use these user accounts to sign into services and applications protected through Entra ID.
The primary scenario we are describing in this article is an organization with an Entra ID tenant that wants to collaborate and invite end users as guests from another organization that uses Google Workspace to access its application and services. Note that we aren’t interested in self-service signup user flows; that is, the Entra ID organization will proactively invite end users from the Google Workspace organization to access its applications, rather than allow end users from the Google Workspace organization to sign-up on their own in a self-service manner. Also, note that the intention is for end users to sign in with their Google Workspace credentials, and achieve single sign-on (SSO).
Note that RP means relying party and represents the application the end user is attempting to access. Google Workspace, in this case, is our identity provider (IdP).
The following high-level architecture diagram demonstrates the flow:
The arrows indicate that the objective is to perform RP-initiated sign-in, whereby an end user navigates to the RP and is then redirected to Entra ID for authentication. Entra ID, in turn, redirects the user to authenticate with their Google Workspace user account. After successful authentication with Google, the end user is redirected back to Entra ID, and then back again to the RP, where they are now signed-in!
At this point, you may be wondering, what about Gmail user accounts? If an end user has a Gmail account, which is an example of a social account, rather than an enterprise account such as Google Workspace, how would they sign in?
Microsoft describes how to setup a federation with Google at https://learn.microsoft.com/en-us/entra/external-id/google-federation, but it clearly states the following:
Google federation is designed specifically for Gmail users. To federate with Google Workspace domains, use SAML/WS-Fed identity provider federation.
It is critical to understand that, in our architecture, the authentication proxy/broker is an Entra ID tenant with the workforce configuration, not an Entra ID tenant with the external configuration (which is designed for customer identity and access management use cases).
So, at the time of writing, if you want to support Gmail users (i.e. someone@gmail.com), you can easily setup a modern OAuth 2.0/OpenID Connect identity federation. However, for the purpose of this article, if you are interested in enterprise accounts from a Google Workspace, you need to setup a SAML 2.0 identity federation, and you would have to do this for each specific domain you want to target, and work with the organization that uses Google Workspace so that they can setup a custom SAML app on their end as well.
As a result, with every company that uses Google Workspace, you need to talk to their IT team and provide them with your Entra ID tenant metadata (such as the Assertion Consumer Service URL and Entity ID), and then they would also, in turn, provide you with their metadata, such as SSO URL, Entity ID, and certificate information.
You may be thinking, is this a Google issue or a Microsoft issue? Why is this the case? Many organizations use Google Workspace, so why do I have to set up a custom SAML integration with every one of them?
It turns out that it’s a Microsoft limitation, not a Google limitation. Google Workspace and Gmail are services that are both accessed via a Google Account. Therefore, for Google, it doesn’t matter if the end user will type in someone@gmail.com or someone@organization.com. Anyone logging into Google services will have a Google Account. In fact, you can easily create a Google Account without Gmail.
The primary reason Microsoft Entra ID has this limitation is because of a process known as home realm discovery (HRD). Entra ID with the workforce configuration does HRD based on the domain name. If an end user lands on the Entra ID sign in screen, and types in, someone@gmail.com, they will be redirected to their Google Account, and successfully sign into the RP (assuming Google federation was setup).
However, since we want to sign in a user with their Google Workspace account, then we have no choice but to setup a domain-based SAML 2.0 identity provider federation with that organization. Why? Because there isn’t a way to display a “Sign in with Google” button on the Entra ID sign-in options when you invite users to your Entra tenant for collaboration. Entra ID would only redirect the end user to Google after it determines that the email domain the user entered on the sign-in screen is federated with Google.
As a result, there is no simple way to display the following Sign-in options on Entra ID with the “Sign in with Google” option:
In fact, the only way to display a “Sign in with Google” option in Entra ID for workforce tenants, is via self-service signup user flows, but that isn’t the scenario we are targeting in this article.
In conclusion, there really shouldn’t be this limitation on the Microsoft side because Google will ask the end user for their Google Account, and that’s regardless of whether or not it’s Gmail or Google Workspace. Entra External ID for workforce tenants, however, cannot simply customize the HRD user experience (UX) to display a “Sign in with Google” option. If it could, it would be possible to simply set up a modern OAuth 2.0/OpenID Connect integration with any Google Account once, and it would work for any Google Account – both social and enterprise user accounts alike!
To be pedantic, if you have a customer identity and access management tenant (i.e. external tenant configuration), you can easily setup Google as an identity provider, and it would work for any Google Account, regardless of whether it’s Gmail or Google Workspace, since there will be a “Sign in with Google” option, as the screenshot below demonstrates – it works both for social Gmail user accounts and enterprise Google Workspace user accounts:
Hopefully, Microsoft will address this limitation in the future, and that will enable Entra ID tenants in the workforce configuration to invite ends users to collaborate with the organization using any Google Account the end user has, whether it’s a social or enterprise account, via a single modern OAuth 2.0/OpenID Connect identity federation.
For Microsoft Entra organizations that work with many other enterprises that use Google Workspace, it isn’t practical to setup a custom SAML 2.0 identity federation for every single organization on a 1:1 basis, and so a generic Sign in with Google button that works for every type of Google Account is a much needed capability!