Skip to main content
This guide sets up Enterprise SSO with Google Workspace using OIDC. Read the overview first if you haven’t — it covers domain verification, roles, and the limitations that apply to every provider. Google’s consoles are redesigned regularly, so treat the menu paths and field labels below as a guide; the exact labels move between releases.

Why OIDC and not SAML

Google Workspace can also act as a SAML identity provider, but Modem recommends OIDC here. Google’s OIDC sub claim is a stable, globally unique user id — Google’s discovery document advertises subject_types_supported: ["public"] — so there is no identifier to map and nothing to get wrong. With SAML you would have to choose and configure one yourself.

Prerequisites

  • Enterprise SSO enabled for your Modem organization, and the owner role in it
  • Access to the Google Cloud project attached to your Workspace, with permission to create OAuth credentials
  • Access to DNS for the email domain you are claiming
Unlike Okta and Entra, this integration is created in the Google Cloud Console, not in the Google Workspace Admin console. The Admin console is only involved if you want to restrict which users can reach the app.

Setup

Unlike the SAML providers, this one is a single pass: Modem’s redirect URI is available before you register anything, so there is no placeholder to come back and replace.
1

Copy Modem's redirect URI

In the Modem dashboard, go to SettingsSSO. Copy the OIDC redirect URI, which looks like https://app.modem.dev/api/auth/sso/callback/org-<id>.
2

Configure the OAuth consent screen

In the Google Cloud Console for the project attached to your Workspace, open APIs & ServicesOAuth consent screen and set the user type to Internal, so only users in your Workspace can use the app.
3

Create the OAuth client

Go to APIs & ServicesCredentialsCreate credentialsOAuth client ID, and choose the application type Web application. Give it a name such as Modem.Under Authorized redirect URIs, add the redirect URI you copied in step 1, exactly as Modem shows it.
4

Copy the client id and secret

Create the client and copy the Client ID and Client secret. The secret is shown once — if you lose it, create a new one rather than guessing.
5

Register Google in Modem

Back on the Modem SSO settings page, choose OIDC and enter:Modem reads Google’s discovery document from the issuer to fill in the authorization, token, and JWKS endpoints, and always uses PKCE. Enter the email domain you are claiming at the same time.
6

Verify your email domain

Publish the DNS TXT record Modem shows on the SSO settings page and click verify. Sign-in is refused until this succeeds — see Domain verification.

Scopes

Modem requests three scopes:

The identity Modem stores

Modem stores the OIDC sub claim as the account identity. There is nothing to configure — Google’s sub is already a stable, globally unique id for the user, and it does not change when someone’s email address does.
Directory Sync matches directory users to Modem users by externalId, which has to be the same value Modem stores here — the sub claim — never the email address. Modem has setup guides for provisioning from Okta and Microsoft Entra ID; Google Workspace provisioning is not covered by a guide yet.

Restricting who can sign in

Because the consent screen is Internal, only users in your Workspace can complete the flow, and Modem additionally requires the user’s email domain to be the verified domain on the SSO settings page. That still means any Workspace user who can reach the consent screen and whose address is on the verified domain can sign in. If you need a narrower set of people, restrict access to the app from the Google Workspace Admin console rather than relying on the Modem side.

Testing the sign-in

Sign out of Modem, or use a private window, then:
  1. Go to https://app.modem.dev
  2. Click Continue with SSO
  3. Enter your work email address, or your Modem organization slug
  4. Complete the Google prompt
You should land back in Modem signed in. A user who has never used Modem before gets an account and joins as a member, unless they had a pending invitation carrying a different role.
Start from the Modem sign-in page. Modem accepts SP-initiated sign-in only, so launching from an app tile or a bookmarked Google URL is rejected with “Start single sign-on from Modem”. This is the single most common support question — it is worth telling your team up front.

Troubleshooting

The redirect URI registered on the OAuth client does not match Modem’s exactly. Copy it again from the SSO settings page — it ends in your organization’s provider id, org-<id>, and Google compares the whole string character for character, including the scheme and any trailing characters.
The domain has not been verified yet. Publish the DNS TXT record from the SSO settings page and click verify. DNS can take minutes to hours to propagate; retrying is safe.
The address typed at Continue with SSO is not on the verified domain. Personal Google accounts, and Workspace users on a secondary domain you have not verified, will not resolve to your provider.
The consent screen is Internal, so users outside your Workspace are refused by Google before the flow reaches Modem. Check the user’s account, and any app access restrictions set in the Google Workspace Admin console.
Modem holds the secret it was given, so rotating it in Google Cloud breaks the exchange. Enter the new secret on the Modem SSO settings page.

Enterprise SSO

Requirements, domain verification, and sign-in behaviour.

Team Management

Roles, invitations, and auto-join.