Google Workspace supports SAML 2.0 and OIDC for single sign-on, and the entire job comes down to four moves: create an SSO profile in the Admin console, configure your identity provider with that profileβs Entity ID, ACS URL, and certificate, assign the profile to an organizational unit or group, then verify it with an IdP-initiated and SP-initiated test. If youβre still running a legacy SAML profile, Google recommends migrating to the newer SSO profile model for better group targeting and OIDC support.
TL;DR:
SAML is preferred for legacy, enterprise environments, or apps that require XML assertions, while OIDC is better suited for modern web and mobile apps using JSON tokens.
Proper setup of SAML profiles involves verifying Entity IDs, ACS URLs, certificates, and attribute mappings to prevent common sign-in errors.
Assign SSO profiles at the organizational or group level, starting with pilot groups to avoid widespread issues and ensure smooth deployment.
Regularly rotating certificates, testing login flows, and monitoring sign-in logs help maintain SSO reliability and security over time.
Pair SSO with context-aware access, strong MFA, and automated provisioning to enhance security and reduce risks associated with centralized authentication.
Table of Contents
When Should You Use SAML Instead of OIDC?
Both protocols exist in Google Workspace for a reason, and picking wrong just means more troubleshooting later.
SAML 2.0 has been the enterprise default for years because it works with a huge range of existing SaaS applications that were built around XML assertions and browser redirects. If your organization runs older line-of-business apps or an identity provider that only speaks SAML, that decision is already made for you.
OIDC, built on OAuth 2.0, tends to fit better with modern web apps, mobile clients, and API-driven services that expect JSON tokens instead of XML. Itβs also generally easier to debug, since ID tokens are simpler to inspect than signed SAML assertions.
Choose SAML when your IdP or downstream apps require it, or when youβre integrating with legacy enterprise software.
Choose OIDC for modern app stacks, mobile-first tools, or when your IdP offers a preconfigured OIDC connector.
Run both if your app portfolio is mixed. Google Workspace supports multiple IdPs simultaneously, so youβre not locked into one protocol organization-wide.
How Do You Set Up a SAML SSO Profile in Google Admin?
Configuring SAML correctly the first time saves you a week of chasing sign-in errors later.
In the Admin console, go to Security > Authentication > SSO with third-party IdP.
Click Add SAML SSO profile and give it a clear name (something tied to the IdP, not just βSSO1β).
Enter your IdPβs Entity ID, Sign-in page URL, Sign-out page URL, and (optionally) a Change password URL.
Copy the ACS URL and Googleβs own Entity ID from the Admin console, then paste them into your IdPβs configuration.
Upload your IdPβs public certificate. Google requires signed SAML assertions using the SAML 2.0 HTTP POST binding, so an unsigned or misconfigured cert is one of the most common launch blockers.
Confirm the NameID format matches what your IdP sends (email address is the usual choice) and set up any attribute mapping you need.
Keep group assignments modest at first. A profile assigned to a single pilot group is far easier to unwind than one pushed to your entire domain.
Pro Tip: Stand up a dedicated test OU with two or three throwaway accounts before you touch production users. It turns a risky rollout into a boring one.
How Do You Configure an OIDC Profile for Workspace?
OIDC profiles live in the same Admin console location as SAML, under Security > Authentication > SSO with third-party IdP, but the fields look different.
Add a new OIDC profile and choose between a custom integration or the preconfigured Microsoft Entra ID profile, which auto-fills much of the setup.
For a custom profile, supply the Issuer URL, Client ID, Client secret, and confirm the Redirect URI Google generates matches whatβs registered on the IdP side.
Custom OIDC gives you more control over scopes and claims; the Entra preconfigured option trades some flexibility for a faster setup if Entra ID is already your directory source.
OIDC tends to be a better fit if your organization is building or buying modern SaaS tools rather than maintaining legacy SAML-only systems.
How Should You Assign SSO Profiles to Users?
Google Workspace assigns SSO profiles at the OU or group level. Thereβs no per-user toggle, which is intentional. It forces you to think in terms of scope rather than one-off exceptions.
Apply a profile to an OU for department- or company-wide rollouts, and use groups when you need finer targeting across OU boundaries.
Set a profile assignment to None for any OU that should keep using Googleβs own password authentication, such as service accounts or an emergency admin.
Stage rollouts by assigning the new profile to a pilot OU or group first, watching sign-in logs for a few days, then expanding.
Domain-specific service URLs let you route sign-ins differently across multiple domains under one Workspace account, which matters if youβve merged organizations or run separate brands.
Itβs the only way to catch a bad ACS URL before it locks out your whole company.
What Should You Check When Testing SSO?
Testing is where most SSO problems get caught, or missed.
Use the Admin consoleβs Test SAML login feature to run an IdP-initiated test before assigning the profile broadly.
Separately test an SP-initiated flow by starting from a Google sign-in page (like
gmail.com) to confirm the redirect to your IdP works both directions.Inspect the SAML assertion or OIDC ID token for a correct NameID, expected attributes, a valid signature, and timestamps that havenβt expired.
If login fails, check for clock skew between your IdP and Google, a certificate that doesnβt match whatβs uploaded, or an ACS URL/Entity ID mismatch. Google Cloudβs architecture guidance covers this assertion flow in detail if you need to trace exactly where the handshake breaks.
Confirm the test user actually exists in Workspace with matching attributes. A perfectly valid assertion still fails if thereβs no provisioned account to match it to.
What Maintenance Keeps SSO Reliable Long Term?
SSO isnβt a set-it-and-forget-it configuration. A few recurring tasks keep it from breaking quietly.
Upload a second certificate ahead of your current oneβs expiration so you can rotate without downtime. Googleβs own guidance recommends making the switch at least 24 hours in advance of when the old certificate actually expires.
Turn on Autofill email so the sign-in page pre-populates the userβs address using the login hint parameter, which shaves a step off every login.
Review network masks if youβre restricting sign-in by IP range, and check domain-specific service URLs whenever you add a new domain to the account.
Decide whether to enforce post-SSO verification, which layers an additional 2-step verification challenge on top of the IdPβs own authentication.
Pro Tip: Put a recurring calendar reminder 30 days before every certificate expiration. Nobody remembers this until the day logins start failing.
What Security Controls Should Pair With SSO?
SSO centralizes authentication, but that only reduces risk if you back it with the right controls around it.
Turn on Context-Aware Access so sign-ins get evaluated against device posture, location, and IP, not just a valid password. Combining SSO with these guardrails is one of the clearer wins in a Zero Trust model for teams that arenβt all working from a single office network.
Require phishing-resistant MFA, ideally FIDO2 security keys, rather than SMS codes that are easier to intercept.
Automate provisioning and deprovisioning through directory sync where your IdP supports it. Manual account reconciliation is the most common gap between when someone leaves and when their access actually gets revoked.
Review Admin console audit logs regularly. SSO activity logs show you sign-in patterns that flag compromised credentials before they escalate.
Migrating off legacy SAML profiles matters here too. Legacy profiles donβt support the same group-based assignment or newer provisioning options, which means a smaller, harder-to-audit attack surface than modern SSO profiles.
Why Do SSO Errors Happen, and How Do You Fix Them?
Most SSO failures trace back to a short list of causes.
Signature or certificate errors almost always mean the uploaded certificate doesnβt match what the IdP is signing with. Re-export and re-upload it.
ACS URL or Entity ID mismatches show up as a generic βcanβt complete sign-inβ error. Compare both values character by character between Google and your IdP.
NameID format mismatches cause a valid-looking assertion to fail silently. Confirm the format (email versus persistent ID) matches on both ends.
Isolate any issue with a single test account before touching production users, and capture the raw SAML response or the exact Admin console error text.
If the problem persists after checking these, itβs usually time to loop in your IdP vendorβs support team or Google Workspace support directly.
How Does Operations Tooling Fit Into the SSO Lifecycle?
SSO handles authentication, while your team still needs to organize the work around employee arrivals and departures. CentriOps brings user records, devices, tasks, and checklists into one workspace to help teams track onboarding and offboarding work. Teams can outline steps such as assigning equipment and removing accounts, then carry out and verify those changes in Google Workspace or their identity provider.
β CentriOps Team
Manage the Access Lifecycle Around Your SSO Setup
Getting SSO configured is one part of supporting your team. You also need to organize device records, track tasks, and follow a clear process when employees join or leave. CentriOps helps small and mid sized businesses bring this operational work into one workspace, with users, devices, subscriptions, tasks, and checklists.
Use CentriOps checklists to document onboarding and offboarding steps, and tasks to track the work your team needs to complete. Keep user and device records organized alongside that work, while making and verifying account changes directly in Google Workspace and other services. Explore the CentriOps features or start a 30 day free trial to see how it fits your teamβs daily operations.
Sources
Single sign-on | Cloud Architecture Center | Google Cloud Documentation
Optional SSO settings and maintenance | Google Workspace Help
