How do I make my product work with Google Workspace SSO?

To make your product work with Google Workspace SSO, you typically need to support Google as an Identity Provider (IdP) using OpenID Connect (OIDC) or SAML 2.0.

Recommended approach

For most modern apps, use OpenID Connect (OIDC) with Google Workspace. It’s simpler than SAML and works well for web apps and many mobile/native flows.

---

What you need to do

1) Decide what “SSO” means for your product

Usually there are two parts:

• Authentication: let users sign in with their Google Workspace account
• Organization enforcement: only allow users from a specific Google Workspace domain, if needed

If you need enterprise onboarding, you may also want:

• domain verification
• SCIM provisioning
• admin-managed SSO setup

---

2) Create a Google Cloud project

In the Google Cloud Console:

1. Create or choose a project
2. Configure the OAuth consent screen
   • Set app name
   • Add your support email
   • Add authorized domains
   • Choose internal vs external if appropriate
3. Create OAuth 2.0 credentials
   • Web application client for browser-based apps
   • Add redirect URIs

You’ll get:

• Client ID
• Client Secret (for confidential web backends)

---

3) Implement Google sign-in with OIDC

Use the Authorization Code flow:

1. Redirect user to Google’s authorization endpoint
2. User authenticates with Workspace
3. Google redirects back with an authorization code
4. Your backend exchanges the code for tokens
5. Verify the ID token
6. Create a session in your app

Important claims to validate in the ID token:

• iss — issuer
• aud — must match your client ID
• exp — not expired
• email
• email_verified
• sub — stable Google user identifier

If you need to restrict to a Workspace domain, check:

• hd claim, or
• the user’s email domain, depending on your security requirements

---

4) Restrict access to a specific Workspace domain

If your product should only allow users from a certain organization:

• Verify the user’s email domain matches example.com
• Prefer also checking the hd claim when available
• Do not rely only on the UI or client-side checks

Be aware:

• Some Google accounts may have the same email domain-like appearance without being Workspace-managed
• Domain restriction is stronger when enforced server-side

---

5) Support admin consent / enterprise setup

If the customer wants centralized control, they may want an admin to authorize your app.

Depending on the use case:

• For OIDC login only, admins usually don’t need to pre-authorize anything beyond tenant policies
• For Google APIs access, you may need OAuth scopes and admin approval
• For SAML SSO, admins will configure your app in Google Admin Console

---

If you want true enterprise SSO, consider SAML too

Google Workspace supports SAML apps via the Admin console.

This is useful when:

• Enterprise customers expect SSO configured by admins
• Your app already supports SAML with other IdPs
• You want Google Workspace to be the IdP for a workforce app

Typical SAML setup:

1. Your app exposes a SAML ACS endpoint
2. Google Admin sets up a custom SAML app
3. Admin downloads Google IdP metadata or certificate
4. Your app verifies SAML assertions
5. You map NameID / attributes to a user in your system

---

Security best practices

• Always use HTTPS
• Use the Authorization Code flow with PKCE for public clients
• Verify tokens on the server, not just in the browser
• Use short-lived sessions and secure cookies
• Check issuer, audience, expiry, and signature on ID tokens
• Never trust email alone without verifying the token
• Store Google user ID (sub) as the primary external identifier

---

Product architecture options

Option A: “Sign in with Google”

Best if you just want users to authenticate with Google Workspace accounts.

Option B: “Workspace SSO with domain restriction”

Best if only employees of a customer org should access the app.

Option C: “Enterprise SAML SSO”

Best if you want admin-managed SSO setup for businesses.

---

Common implementation libraries

Depending on your stack:

• Node.js: openid-client, Google auth libraries
• Python: google-auth, authlib
• Ruby: omniauth-google-oauth2
• Java: Google OAuth client libraries
• Go: golang.org/x/oauth2, OIDC libraries

---

If you also need provisioning

If customers want lifecycle management:

• SCIM for automatic user provisioning/deprovisioning
• SSO for login
• SCIM for account creation and access revocation

---

Practical recommendation

If you’re building a SaaS product:

1. Start with Google OAuth/OIDC login
2. Add domain restriction
3. Later add SAML SSO for enterprise plans if customers request it
4. Add SCIM if you need automated provisioning

If you want, I can give you:

• a step-by-step Google OIDC integration guide
• a SAML setup guide for Google Workspace
• or sample code for your stack (Node, Python, Java, etc.)