This guide is written by the team that builds Casdoor and describes the standards as published (listed under Sources), with notes on how Casdoor implements them as of November 8, 2026. Spotted a mistake? Tell us.
"Google Workspace SSO" means two different things, and the setup is opposite in each direction:
- Google Workspace is the service provider: a third-party identity provider such as Entra ID, Okta or Casdoor signs users in to Google Workspace.
- Google Workspace is the identity provider: Google signs users in to third-party applications over SAML.
Most organizations need one direction, some need both. The admin console paths and metadata are different, and mixing them up is the usual reason a setup does not work.
Direction 1: a third-party IdP signs users in to Google
This is the configuration people mean when they say "Google Workspace SSO with Entra ID" or "with Okta". Google Workspace stops asking for its own password and trusts the identity provider.
What Google needs
In the Google Admin console:
- Open Security > Authentication > SSO with third-party IdP.
- Choose Set up SSO with third-party identity provider.
- Provide the IdP's sign-in page URL, sign-out page URL and change-password URL, and upload the IdP's verification certificate.
- Optionally upload the IdP metadata instead of entering the fields by hand.
- Test with a super admin account before turning it on for everyone.
What the identity provider needs
Create a SAML application in the identity provider with:
- ACS URL: the Google Workspace assertion consumer service URL shown in the admin console.
- Entity ID: the Google Workspace entity ID shown in the same place.
- NameID: the user's primary email address, in the format Google expects.
- Attributes: at least the primary email; first name, last name and groups are optional but useful.
Keep a super admin account with a Google password as a break-glass path. If the identity provider is down or misconfigured, SSO-only access locks everyone out of the admin console.
Direction 2: Google Workspace signs users in to an app
This is the configuration for "sign in with Google" inside a third-party application, using Google as the SAML IdP.
Create the custom SAML app
In the Google Admin console:
- Open Apps > Web and mobile apps > Add app > Add custom SAML app.
- Name the app and download the IdP metadata: the SSO URL, entity ID and certificate.
- Enter the application's ACS URL and entity ID.
- Choose the Name ID format the application expects, usually the email address.
- Map attributes: primary email, first name, last name and any groups the app needs.
- Turn the app on for the right organizational units.
Then configure the application with the metadata from step 2. The certificate is the part that expires: set a reminder before it does, or the app stops accepting logins.
Which direction do I need?
| Goal | Google's role | Where to configure |
|---|---|---|
| Employees sign in to Google Workspace through Entra ID or Okta | Service provider | Admin console: Security > Authentication > SSO |
| An application accepts "Sign in with Google" over SAML | Identity provider | Admin console: Apps > Web and mobile apps > Custom SAML app |
| An application accepts Google login over OIDC | Identity provider | Google Identity / OAuth client in the Google Cloud console |
| Employees use Google as a social login in your product | Identity provider | Casdoor or your IdP's Google provider |
The last two are often confused. Google Workspace's enterprise app SSO uses SAML. OIDC is available through Google Identity for applications that use Google sign-in directly.
Common errors
| Symptom | Usual cause |
|---|---|
| "App is not configured" or a redirect loop | ACS URL or entity ID does not exactly match the app's configuration |
| Google rejects the assertion | Certificate expired, or the NameID is not the primary email |
| Users sign in but the app has no name or email | Attribute mapping missing or attribute names do not match |
| Admin console locked out | SSO enforced without a break-glass super admin |
| Some users bypass SSO | Organizational unit not covered by the SSO profile |
Where Casdoor fits
Casdoor can sit on either side:
- As the identity provider for Google Workspace, it creates the SAML assertion Google expects, with MFA, passkeys and organization-specific policies applied before the assertion is issued.
- As the broker in front of Google, it lets users sign in with their Google account while Casdoor keeps its own accounts, roles and groups.
That second pattern is common when an application should accept Google login but the organization also needs a local user directory, SCIM provisioning and audit logs. Self-host Casdoor for free, or run a dedicated instance on Casdoor Cloud from $6.67/month billed yearly. Related reading: SAML SSO, SAML IdP setup and SAML attribute mapping.
FAQ
Does Google Workspace support SSO with Entra ID? Yes. Entra ID can act as the third-party identity provider for Google Workspace over SAML, configured in the Google Admin console.
Does Google Workspace support OIDC? Google Workspace's built-in enterprise SSO uses SAML. OIDC is available through Google Identity for applications that use Google sign-in, and through Google Cloud OAuth clients.
Can I use Google Workspace as an identity provider for my app? Yes, as a custom SAML app in the Google Admin console, with Google providing the IdP metadata and the app providing an ACS URL and entity ID.
What happens if the identity provider goes down? Users cannot sign in to Google Workspace. Keep a break-glass super admin with a Google password, and monitor the IdP as a critical service.
Is Google Workspace SSO free? SSO configuration is part of Google Workspace administration. The identity provider you use may charge separately; Casdoor is free to self-host.
Sources
- Google Workspace: set up SSO with a third-party IdP
- Google Workspace: set up a custom SAML app
- Google Workspace: SAML attribute mapping
- Casdoor docs: Google provider
Product names are trademarks of their respective owners.