Google Workspace
Connect a Grovs project to Google Workspace so your team signs in with their Google account.
Google Workspace is an OpenID Connect provider, so it connects to Grovs the same way as any other identity provider: an OAuth client in Google Cloud, and the issuer, client ID, and client secret in Grovs. You need a Google Workspace super administrator for the Google steps and admin rights on the Grovs project.
This is different from the "Continue with Google" button that every Grovs user has. That button signs in any Google account. Enterprise SSO ties sign-in to your Workspace, verifies your email domains, and lets you make it the only way in.
Two things Google does differently
No admin role in the token. Grovs promotes a person to project admin when the ID token carries a role or group value you configure. Google ID tokens contain no roles or groups, so leave the admin role field empty and make people admins under Team Members in Grovs.
No SCIM. Google Workspace only provisions accounts automatically into apps in its own SAML catalog, and Grovs uses OpenID Connect. Joiners are created on their first sign-in, and leavers are handled as described below.
Create the OAuth client in Google Cloud
Pick a Google Cloud project
Open the Google Cloud console with your Workspace admin account and select or create a project to hold the client. Any project in your organisation works; it is only a container for the credentials.
Configure the OAuth consent screen
APIs & Services → OAuth consent screen. Choose Internal as the user type. This is what restricts sign-in to accounts in your Workspace; an External app would accept any Google account whose email happens to be on your domain. Give the app a name such as Grovs, set the support and developer contact emails, and save. No scopes need to be added on this screen: Grovs requests only openid, email, and profile, which are not sensitive.
Create the client
APIs & Services → Credentials → Create credentials → OAuth client ID. Application type Web application. Name it, and under Authorized redirect URIs paste the redirect URI from Grovs: Settings → Single sign-on shows it before and after setup. On the SaaS product it is https://sqd.link/api/v1/identity/sso/auth/oidc/callback. Leave Authorized JavaScript origins empty.
Copy the client ID and secret
Google shows the Client ID and Client secret once the client is created. Copy both. The secret can be viewed again later from the client's page, unlike Entra.
The issuer for every Google Workspace tenant is the same:
https://accounts.google.comGrovs fetches https://accounts.google.com/.well-known/openid-configuration when you save, and validates tokens against Google's published keys with PKCE on every request.
Connect it in Grovs
Create the connection
Settings → Single sign-on → Set up. Enter the Issuer URL https://accounts.google.com, the Client ID and Client secret from Google, leave Admin role value empty, and list your Workspace Email domains, one per line. Saving fetches Google's discovery document, so a typo in the client ID is not caught here; it surfaces as a Google error on the first sign-in.
Verify your domains (SaaS)
Each domain shows a TXT record: name _grovs-sso.<domain>, value grovs-sso-verification=<token>. Add it at your DNS provider and press Verify. Self-hosted deployments skip this; domains are verified on save. The connection becomes active once one domain is verified.
Sign in through the organisation
Open the login page in a private window, type your work email, and press Continue with your organisation. Complete the Google sign-in. You land on the dashboard with your existing role.
Make the first admins
Because Google carries no role claim, everyone who signs in for the first time is a member. Under Team Members, promote the people who should administer the project.
Require single sign-on
Back in Settings, switch on Require single sign-on and confirm. Everyone on the verified domains is signed out and can only sign in through Google from now on. Sign in through Google yourself before doing this.
Controlling who can sign in
With an Internal OAuth client, every account in your Workspace can reach Grovs. To narrow that:
- By organisational unit or group in Google. In the Google Admin console, go to Security → Access and data control → API controls → Manage Third-Party App Access, add the Grovs client by its client ID, and set it to Blocked for the organisation and Trusted or Limited for the units or groups that should have access. Google refuses the sign-in for everyone else, so they never reach Grovs.
- By invitation in Grovs. Turn off account creation on first sign-in, the connection's
jit_provisionsetting. It is on by default and is not yet exposed in the dashboard; set it tofalsethrough the SSO connection API. Then only people who already have a Grovs account, or a pending invitation, can sign in; everyone else sees "No account exists for this email. Ask an administrator to invite you."
Joiners and leavers
- Joiners get a Grovs account and project membership on their first sign-in, as long as their email is on a verified domain.
- Leavers must be removed in two places. Suspending or deleting the account in Google stops them signing in through SSO immediately. With enforcement on, that is the only way they could sign in, so access ends there. Their Grovs membership stays until an admin removes them under Team Members, which you should do so they no longer appear on the team and cannot be reactivated by mistake.
- Renames are not synced. A changed display name in Google is not reflected in Grovs until the person edits their profile.
If you need directory-driven provisioning, SCIM is available from identity providers that support it for custom applications, such as Microsoft Entra ID.
Troubleshooting
"Error 403: org_internal" on the Google screen. The account is not in your Workspace. Expected for external accounts; if it is one of yours, the user's account is in a different Google organisation than the OAuth client.
"Error 400: redirect_uri_mismatch". The redirect URI in the OAuth client does not match the one Grovs shows exactly, including scheme and path. Copy it again from Settings → Single sign-on.
"This email domain is not enabled for single sign-on." The account's primary email is not on a verified domain of the connection. Common with alias domains: Google signs the person in with their primary address, so verify the primary domain too.
"Access blocked: app is blocked" from Google. The client is set to Blocked for that user in Manage Third-Party App Access. Adjust the unit or group setting.
Signed in as the wrong Google account. Google keeps its own session. Grovs passes the typed email as a hint so Google prompts for that account, but if you switch users often, sign out of Google too or use a private window per user.
Locked out after enforcing. Self-hosted operators run rake sso:disable_enforce[<instance_id>] on the backend, which turns enforcement off for that project and is written to the audit log. SaaS customers contact support.