Google Workspace SSO proves who the user is — it validates the password and any MFA — but it does not evaluate the device the user is signing in from. Federating Google Workspace to CSE inserts a device-trust and policy check into that sign-in, so access depends on the device and policy, not on the credential alone.

• Device posture, not just identity. A valid credential can still originate from an unmanaged, jailbroken, or compromised device. CSE requires a registered device with a valid certificate that meets the Trust Level your policy defines (for example, disk encryption, OS version, or TrustScore) before sign-in completes.
• One control point for every brokered app. Because CSE is inserted at the Google SSO layer, a single configuration enforces zero trust across every SaaS application Google fronts — with no per-application integration — and it is evaluated on every login.
• Resistance to credential attacks. Stolen passwords, phished sessions, and account takeover fail at the device check even when the credential itself is correct.
• Passwordless option. The device certificate can stand in for the password, removing the phishable secret entirely (see Passwordless authentication).
• Consistent policy for apps with no native device trust. Access decisions are centralized in one CSE policy engine (role and Trust Level) rather than relying on each SaaS vendor’s own controls.

The result is that Google Workspace SSO changes from “the right person signed in” to “the right person, on a trusted device, meeting policy, signed in” — applied uniformly and enforced before access is granted.

• A CSE tenant with Securing Public Applications (IdP-routed applications) enabled, and access to create an IdP-routed application.
• A Google Workspace tenant with the Security Settings administrator privilege (required to configure SSO with a third-party IdP).
• User accounts that already exist in Google Workspace. Google Workspace SSO authenticates existing accounts only — it does not auto-provision users. Account lifecycle must be handled separately (see Provisioning).
• At least one break-glass super administrator account that is excluded from SSO (see Step 3).

Create the application in CSE that exposes the CSE policy engine as an identity provider to Google.

1. In the CSE Command Center, navigate to Private Access > Access Policies and create a Web Policy.
2. Select IdP Routed as the application type.
3. Name the application (for example, Google Workspace Policy Engine).
4. Attach the web policy that defines the zero trust requirements (for example, a registered, trusted device).
5. Register the application.

CSE generates the federation configuration that Google Workspace requires. CSE can federate to Google over OpenID Connect (OIDC) or SAML 2.0:

• OIDC — CSE generates a Client ID, Client secret, and an Issuer / discovery URL. You must also register the redirect (callback) URI that Google provides for its OIDC profile as an allowed redirect URI in the CSE application.
• SAML — CSE generates a Sign-in (SSO) URL, an IdP Entity ID / Issuer, and a signing certificate. You must configure CSE with Google’s Service Provider details (see Step 2).

Tip: Either protocol works. Custom OIDC profiles are generally available in Google Workspace; use an OIDC SSO profile unless your organization standardizes on SAML, in which case use a SAML profile — both are supported.

In this step you register CSE as the third-party identity provider that Google Workspace delegates sign-in to.

1. In the Google Admin console, go to Menu > Security > Authentication > SSO with third-party IdP (direct link: https://admin.google.com/ac/security/sso).
2. In the Third-party SSO profiles section, click Add OIDC profile (or Add SAML profile).
3. Name the profile (for example, CSE Policy Engine).

Option A — OIDC profile

Enter the values generated by CSE in Step 1:

• Client ID — the CSE OIDC client ID.
• Issuer URL — the CSE OIDC issuer / discovery URL.
• Client secret — the CSE OIDC client secret.
• Change password URL — optional; point to your password self-service page if used.

Then copy the redirect URI that Google displays for this profile and register it as an allowed redirect URI in the CSE application from Step 1.

Note: Google requires the OIDC authorization code flow, and the email claim returned by CSE must exactly match the user’s primary Google Workspace email address.

Option B — SAML profile

Enter the IdP values generated by CSE in Step 1:

• IDP entity ID — the CSE IdP Entity ID / Issuer (required).
• Sign-in page URL — the CSE SAML SSO URL (required).
• Sign-out page URL — optional.
• Change password URL — optional.
• Verification certificate — upload the CSE signing certificate (X.509, PEM or DER). Up to two certificates may be uploaded to support rotation.

Then open the profile’s SP details section and copy Google’s Service Provider values into the CSE application:

Warning: Copy the ACS URL and Entity ID verbatim from the SP details section of your profile. The <RPID> value is unique to each profile, and older profiles may use a path-based form (/samlrp/<RPID>/acs). Do not construct these URLs by hand. The legacy org-wide SSO profile uses different values (ACS https://www.google.com/a/<domain>/acs, Entity ID google.com).

Note: The SAML assertion from CSE must use the NameID format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, and the NameID value must be the user’s primary Google Workspace email address (the value is case-sensitive).

This step prevents infinite redirect loops and administrator lockout. In Google Workspace, loop and lockout prevention is built in and reinforced with an exemption.

• Super administrator bypass (built in). When a super administrator signs in at admin.google.com, Google requires the full Google administrator email and Google password — not the SSO credentials — and does not redirect them to the third-party SSO sign-in page. With the modern multi-IdP SSO profiles, super administrators always fall back to Google-password sign-in. This is the native break-glass path if CSE is misconfigured or unavailable.
• Dedicated break-glass account. Maintain at least one super administrator account that is never routed through CSE. Place it in an OU or group that is assigned None in Step 4, and enable 2-Step Verification on it.
• Recovery path. If access is lost, recover at https://accounts.google.com/signin/recovery, or use the Apps Admin Toolbox recovery form (https://toolbox.googleapps.com/apps/recovery/form) with DNS domain-ownership verification. Another super administrator can also reset the password from the Admin console.

Warning: Do not assign the CSE SSO profile to the OU that contains your break-glass administrators, and confirm super-administrator access works before broadening the rollout. Validate sign-in with a single pilot user before assigning the profile to a wider population.

Because Google routes by user population rather than by application, a phased rollout is performed by OU or group.

1. In Security > Authentication > SSO with third-party IdP, open Manage SSO profile assignments.
2. Select a pilot organizational unit or group.
3. Assign the CSE Policy Engine profile (the Another SSO profile option) to that population.
4. Leave all other OUs and groups set to None (Google credentials) or Inherit.

Note: A group assignment overrides an organizational unit assignment for users who belong to that group, which lets you pilot CSE for a specific group regardless of OU placement. SSO profiles cannot be assigned on a per-user basis.

Once the pilot is validated, broaden enforcement to all users.

1. In Manage SSO profile assignments, assign the CSE Policy Engine profile at the root organizational unit so it applies to all users by inheritance.
2. Keep the break-glass OU or group from Step 3 assigned to None.

All assigned users now authenticate through CSE, and zero trust policy is enforced before Google completes sign-in to any brokered SaaS application.

Passwordless authentication

CSE can authenticate users by device certificate without a password. Because CSE owns the interactive sign-in once Google delegates to it, enabling passwordless authentication is a CSE-side configuration on the web policy and the device-trust settings; Google receives only the resulting assertion.

User exemptions

To exclude specific users from CSE enforcement, assign their OU or group to None in Manage SSO profile assignments so that they continue to authenticate with their Google credentials. For the legacy org-wide SSO profile, Network masks (IP ranges in CIDR notation) can additionally restrict which source IP addresses are redirected to SSO; network masks apply only to the legacy profile and only to domain-specific service URLs.

MFA and 2-Step Verification

If CSE (or an upstream identity provider) already enforces multi-factor authentication, Google’s 2-Step Verification can produce a duplicate prompt. Control this with Post-SSO verification:

1. Go to Menu > Security > Authentication > Login challenges.
2. Open Post-SSO verification.
3. To avoid duplicate MFA, set the policy to bypass additional challenges and 2-Step Verification for users who sign in through the CSE SSO profile.

Note: Defaults differ by profile type. The legacy SSO profile bypasses post-SSO challenges by default, whereas the modern SSO profiles apply post-SSO challenges by default. Set the policy explicitly to match your design.

Provisioning

Google Workspace SSO performs authentication only — it does not create accounts. During sign-in, Google matches the assertion’s NameID (or OIDC email claim) to an existing Google Workspace account. Pair SSO with a provisioning mechanism such as Google Cloud Directory Sync (GCDS), Google Workspace Directory Sync, or SCIM-based automated user provisioning so that accounts exist before users attempt to sign in.

• A user on a registered, trusted device is redirected from Google to CSE, satisfies the web policy, and CSE returns an assertion. Google completes sign-in to the SaaS application.
• A user on an untrusted or unregistered device is redirected to CSE but fails the web policy. CSE does not issue an assertion, and the user cannot complete sign-in to the application until the device meets policy.
• A super administrator signing in at admin.google.com is not redirected to CSE and retains direct access with the Google password, preventing lockout.