Setting up Google SSO

Configure Google Workspace as your single sign-on provider — step-by-step admin guide.

Updated 2 Jun 2026

This is the admin guide for connecting Google Workspace as your single sign-on provider. Users sign into Clment with their Google work account.

Prerequisites:

  • Pro or Enterprise plan.
  • A Google Workspace Super Admin role (or delegated admin with API project rights).
  • About 15 minutes.

Step 1: Create an OAuth client in Google Cloud Console

  1. Open console.cloud.google.com and select (or create) a project for your organisation.
  2. APIs & Services → OAuth consent screen.
  3. Choose Internal (so only users in your Google Workspace can sign in via this client) and continue.
  4. Fill in:
    • App name: Clment
    • User support email: an address your users can email.
    • Developer contact: your admin email.
    • Leave logo / domains optional for now.
  5. Scopes: add the following non-sensitive scopes:
    • email
    • profile
    • openid
  6. Test users: skip (internal-only doesn’t need this).
  7. Save and continue.

Step 2: Generate credentials

APIs & Services → Credentials → + Create credentials → OAuth client ID.

  • Application type: Web application.

  • Name: Clment SSO.

  • Authorized redirect URIs:

    • US region: https://identity.us.clment.com/auth/sso/google/callback
    • EU region: https://identity.eu.clment.com/auth/sso/google/callback
    • AU region: https://identity.au.clment.com/auth/sso/google/callback

    Use the URI matching your Clment org’s region. (See Picking your data region.)

Click Create. Copy the Client ID and Client Secret from the dialog that pops up.

Step 3: Configure in Clment

Settings → Security → Single sign-on → Connect Google.

Paste:

  • Client ID from step 2.
  • Client Secret from step 2.

Click Save. Clment validates immediately.

Step 4: Test

Test sign-in button → walks through the flow. Expect:

  1. Google sign-in page.
  2. Consent screen (first time).
  3. Redirect back to Clment, signed in.

Common errors:

  • redirect_uri_mismatch — the URI in Google doesn’t exactly match step 2. Check protocol (https), the host (correct region), and the path (/auth/sso/google/callback, not /auth/google/callback).
  • invalid_scope — the OAuth consent screen doesn’t have email, profile, openid. Re-check step 1.
  • access_denied — the user trying to sign in isn’t in your Workspace. Internal-only clients reject external Google accounts.

Step 5: Disable password sign-in (optional)

Once you’ve confirmed Google SSO works for everyone who needs access:

Settings → Security → Allowed sign-in methods → uncheck Password, leave Google ticked.

Effects:

  • Users who previously signed in with email + password are walked through Google SSO on their next sign-in.
  • The email/password signup form is hidden for your org’s domain.
  • MCP custom connectors continue working — they use a separate token mechanism, not session passwords.

Restricting which Workspace users can sign in

By default, any user in your Workspace can sign in once SSO is configured. To restrict access:

Workspace-side: Google’s OAuth client doesn’t have per-user restrictions when set to Internal. To gate access, restrict the Workspace OU that has access to your Clment app via Workspace’s app-access settings.

For Clment-side user management, invite each user via the Team page in the normal way (Inviting users and roles) — their email needs to match what Google returns at sign-in time.

Switching between Microsoft and Google

You can only have one SSO provider active per organisation at a time. To switch:

  1. Configure the new provider (steps 1–4 above for whichever you’re switching to).
  2. Don’t enforce yet — leave the old one as the active enforcement.
  3. Test the new provider via Test sign-in.
  4. Once happy, swap enforcement to the new provider.
  5. Optionally disable the old provider entirely once everyone has migrated.

Allow some buffer for users to update their saved-password managers etc.

See also

Still have questions?

Instant article search