Setting up Google SSO

Use Google Workspace as your single sign-on provider. You create the OAuth app; the Clment team enables it for your organisation.

Updated 29 Jun 2026

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

SSO is enabled with help from the Clment team. You create the Google OAuth app on your side (below), then we configure and switch it on for your organisation — there’s no self-service SSO screen in the app. To get started, contact support@clment.com and we’ll coordinate the setup, including a secure handover of the credentials.

Prerequisites:

  • A Google Workspace Super Admin role (or delegated admin with API-project rights).
  • About 15 minutes to create the OAuth app.

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: Send the credentials to Clment

There’s no in-app SSO form. Instead, contact support@clment.com with:

  • Your Client ID from step 2.
  • Your Clment org’s region (so we apply the right callback URL).

We’ll arrange a secure way to receive the Client Secret (don’t email it), then configure the connection for your organisation.

Step 4: Confirm it works

Once we’ve configured the connection, we’ll run a test sign-in with you. A successful flow looks like:

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

Common errors we’ll watch for:

  • 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 Google SSO works for everyone who needs access, you can ask us to make it the only sign-in method for your org. Effects:

  • Users who previously signed in with email + password are walked through Google SSO on their next sign-in.
  • Email/password sign-in is turned off for your org.
  • 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 or adding a provider

To add a second provider or switch from one to another, set up the new provider’s OAuth app (steps 1–2) and contact us. We’ll stage the new connection, test it with you, and cut over when you’re ready — leaving a buffer for users to update saved passwords.

See also

Still have questions?

Instant article search