Google Workspace SSO: Set It Up With Your Own Identity Provider

The catch sits in two places. If your sign-in page URL starts with google. or www.google., the Google app on iPhone and iPad gets sent to Safari and sign-in fails. And when a user is in more than one SSO group, the highest-priority group wins, so taking someone out of one group can still leave them redirected through a parent group they inherit from.

SSO profiles: SAML, OIDC or Microsoft Entra

Workspace stores your identity provider settings in SSO profiles. There are three kinds: SAML profiles, custom OIDC profiles, and a default Microsoft Entra OIDC profile that needs no configuration at all. If your team already signs in with Microsoft Entra, that last one is the shortest route.

Profiles are assigned to organisational units or groups, never to individual users. You can also switch SSO off for specific organisational units or groups, which is handy for a pilot.

Setting	As of October 2026
Profiles per organisation	Up to 1,000
Identity provider certificates per profile	Up to 2, so you can rotate them
Service provider certificates per profile	Up to 2, for assertion encryption
Assigned to	Organisational units or groups, not users
Admin privilege needed	Security Settings
Legacy SSO profile	One identity provider only

What to collect from your identity provider first

Before you open the Admin console, get these from your identity provider:

• The entity ID.
• The sign-in page URL.
• The sign-out page URL.
• The change password URL.
• An X.509 certificate in PEM format.

Google's certificate rules are strict. The certificate must be a PEM or DER formatted X.509 certificate with an embedded public key, either DSA or RSA, and that key has to match the private key that signs the SAML response. A mismatch here is the first thing I'd check if a test sign-in fails.

Adding a SAML profile, step by step

1. Make sure your admin account has the Security Settings administrator privilege.
2. In the Admin console, go to Menu, then Security, then Authentication, then SSO with third party IdP.
3. Choose Add SAML profile and enter the entity ID and the sign-in, sign-out and change password URLs.
4. Upload your identity provider certificate. You can hold two, which lets you rotate without downtime.
5. Save the profile, then open SP Details and copy the Entity ID and ACS URL into your identity provider. Both are unique to that profile.
6. If you want encrypted assertions, add up to two service provider certificates to the profile.
7. Assign the profile to an organisational unit or group, starting small.
8. Test sign-in on a computer and on an iPhone before you widen it.

The change password URL reaches everyone

This one surprises people. Once you enter a change password URL, every user except super admins who tries to change their password at myaccount.google.com is sent to your URL, even if SSO isn't switched on for them. So set that URL only when your identity provider's password page is ready for the whole company.

Should you still use the legacy SSO profile?

The legacy profile is the older way of setting up SSO. It supports a single identity provider only, but it has two things the newer profiles don't: network masks based on IP ranges, and SSO for super admins. Its ACS URL follows the pattern accounts.google.com/a/ followed by your domain and /acs, and its entity ID is google.com or google.com/a/ followed by your domain.

Here's the part worth knowing. While the legacy profile is enabled, Google still accepts assertions sent to the legacy ACS URL, even for super admins or users assigned to a different profile. If you've moved everyone to new profiles, that's a good reason to switch the legacy one off.

Three traps that break sign-in

When sign-in breaks, it's usually one of these:

• The iOS URL trap. If the sign-in URL starts with google., googl., www.google. or www.googl., the Google iOS app redirects to Safari and sign-in fails. Use a URL on your own domain or your provider's.
• This domain is not configured to use single sign-on. That error usually means an edition without SSO, which in practice means legacy free G Suite. It can also mean your identity provider is hard-coded to the legacy endpoint.
• Redirected after you removed SSO. Check the group priority order, because the highest-priority group wins. Then check nested groups, since users inherit the profile of a parent group, and finally organisational unit inheritance.

My advice before you switch it on

I'd only bother with SSO if you already run an identity provider for other apps, because then it's one login and one place to switch people off when they leave. If that's you, start with a single small group, test on an iPhone as well as a laptop, and don't touch the change password URL until you're ready for everyone. If you're still picking a provider, my roundup of SSO providers for small businesses is the place to start, and if you're weighing up editions, here's what each Workspace plan costs.

SSO is the plumbing. What your team does once they're signed in, especially with AI, is the part I help with. I run AI training and workshops for teams, and help businesses with AI enablement, AI automation and GEO, which is about getting your business seen and cited in AI answers. Most of that work is with SaaS marketing teams, telecom companies and small businesses. Here's how we can work together.

Frequently asked questions

Does Google Workspace support SSO?

Yes. As of October 2026, every current Workspace edition supports SSO with a third-party identity provider, using SAML or OIDC. Legacy free G Suite doesn't.

Where do I set up SSO in Google Workspace?

In the Admin console, under Menu, Security, Authentication, then SSO with third party IdP. You need the Security Settings administrator privilege.

Can I assign an SSO profile to one user?

No. SSO profiles are assigned to organisational units or groups, not to individual users.

Why does SSO fail on iPhone for Google Workspace?

If the sign-in page URL starts with google., googl., www.google. or www.googl., the Google iOS app is redirected to Safari and sign-in fails.

Why are users still redirected after I removed SSO?

Check group priority order, because the highest-priority group wins, then nested groups, where users inherit a parent group's profile, then organisational unit inheritance.