Implementing Google Workspace SSO Configuration
Overview
Single Sign-On (SSO) for Google Workspace allows organizations to authenticate users through their existing identity provider (IdP) such as Okta, Azure AD (Microsoft Entra ID), or ADFS, rather than managing separate Google passwords. This is implemented using SAML 2.0 protocol where Google Workspace acts as the Service Provider (SP) and the organization's IdP handles authentication. SSO centralizes credential management, enforces MFA policies at the IdP, and enables immediate access revocation when users leave the organization.
When to Use
- When deploying or configuring implementing google workspace sso configuration capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation
Prerequisites
- Google Workspace Business, Enterprise, or Education edition
- Super Admin access to Google Admin Console
- Identity Provider with SAML 2.0 support (Okta, Azure AD, ADFS, Ping Identity)
- IdP signing certificate (X.509 PEM format, RSA or DSA)
- DNS verification for the Google Workspace domain
Core Concepts
SAML 2.0 SSO Flow
User navigates to Google Workspace app (Gmail, Drive, etc.)
│
├── Google checks: Is SSO configured for this domain?
│
├── YES → Redirect user to IdP Sign-In Page URL
│ (SAML AuthnRequest sent via browser redirect)
│
├── User authenticates at IdP (credentials + MFA)
│
├── IdP generates SAML Response with signed assertion
│
├── Browser POSTs SAML Response to Google ACS URL:
│ https://www.google.com/a/{domain}/acs
│
├── Google validates SAML signature against uploaded certificate
│
└── User is granted access to Google Workspace
Key SAML Parameters
| Parameter |
Value |
| ACS URL |
https://www.google.com/a/{your-domain}/acs |
| Entity ID |
google.com/a/{your-domain} or google.com |
| NameID Format |
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| NameID Value |
User's primary Google Workspace email |
| Binding |
HTTP-POST (for ACS), HTTP-Redirect (for SSO URL) |
Workflow
Step 1: Prepare the Identity Provider
For Okta:
- Navigate to Applications > Add Application > Search "Google Workspace"
- Configure the Google Workspace app with your domain
- Assign users/groups to the application
- Download the IdP metadata or note: SSO URL, Entity ID, Certificate
For Azure AD (Microsoft Entra ID):
- Navigate to Enterprise Applications > New Application > Google Cloud/Workspace
- Configure Single sign-on > SAML
- Set Basic SAML Configuration:
- Identifier (Entity ID):
google.com
- Reply URL (ACS):
https://www.google.com/a/{your-domain}/acs
- Sign on URL:
https://www.google.com/a/{your-domain}/ServiceLogin
- Download Federation Metadata XML or Certificate (Base64)
For ADFS:
- Add Relying Party Trust using federation metadata
- Configure claim rules to pass NameID as email address
- Export the token-signing certificate
Step 2: Configure Google Workspace SSO
- Sign in to Google Admin Console (admin.google.com) as Super Admin
- Navigate to Security > Authentication > SSO with third-party IdP
- Click "Add SSO profile" or configure the default profile
Third-Party SSO Profile Settings:
| Setting |
Value |
| Set up SSO with third-party IdP |
Enabled |
| Sign-in page URL |
IdP's SAML SSO endpoint (e.g., https://idp.example.com/sso/saml) |
| Sign-out page URL |
IdP's logout URL (e.g., https://idp.example.com/slo) |
| Change password URL |
IdP's password change URL |
| Verification certificate |
Upload IdP's X.509 signing certificate |
| Use a domain-specific issuer |
Enabled (uses google.com/a/{domain} as entity ID) |
Step 3: Assign SSO Profile to Users
SSO profiles can be applied at different scopes:
Organization-wide (all users)
│
├── Org Unit level (specific departments)
│ ├── Engineering OU → SSO via Okta
│ ├── Marketing OU → SSO via Azure AD
│ └── Contractors OU → SSO via specific IdP
│
└── Group level (specific security groups)
└── VPN Users → SSO with additional MFA
- Navigate to Security > Authentication > SSO with third-party IdP
- Select the SSO profile to assign
- Choose organizational units or groups
- Save and wait for propagation (up to 24 hours, typically minutes)
Step 4: Configure Network Masks (Optional)
Network masks control when SSO is enforced based on the user's IP:
- If the user's IP matches a network mask, they use Google's sign-in page
- If the user's IP does NOT match, they are redirected to the IdP
This is useful for allowing direct Google login from corporate network while enforcing SSO for external access.
Step 5: Test SSO
- Open an incognito browser window
- Navigate to
https://mail.google.com/a/{your-domain}
- Verify redirect to IdP sign-in page
- Authenticate at the IdP
- Verify successful redirect back to Google Workspace
- Test sign-out flow redirects to IdP logout page
- Test with user not assigned in IdP (should fail)
Validation Checklist
References
1---2name: implementing-google-workspace-sso-configuration3description: Configures SAML 2.0 single sign-on for Google Workspace against a third-party identity provider (Okta, Azure AD/Entra ID, ADFS), with Workspace as the Service Provider, to centralize authentication and enable immediate access revocation. Use when setting up or troubleshooting Google Workspace SSO/SAML federation or migrating from native Google passwords to an external IdP.4license: Apache-2.05---6
7# Implementing Google Workspace SSO Configuration
8
9## Overview
10
11Single Sign-On (SSO) for Google Workspace allows organizations to authenticate users through their existing identity provider (IdP) such as Okta, Azure AD (Microsoft Entra ID), or ADFS, rather than managing separate Google passwords. This is implemented using SAML 2.0 protocol where Google Workspace acts as the Service Provider (SP) and the organization's IdP handles authentication. SSO centralizes credential management, enforces MFA policies at the IdP, and enables immediate access revocation when users leave the organization.
12
13
14## When to Use
15
16- When deploying or configuring implementing google workspace sso configuration capabilities in your environment
17- When establishing security controls aligned to compliance requirements
18- When building or improving security architecture for this domain
19- When conducting security assessments that require this implementation
20
21## Prerequisites
22
23- Google Workspace Business, Enterprise, or Education edition
24- Super Admin access to Google Admin Console
25- Identity Provider with SAML 2.0 support (Okta, Azure AD, ADFS, Ping Identity)
26- IdP signing certificate (X.509 PEM format, RSA or DSA)
27- DNS verification for the Google Workspace domain
28
29## Core Concepts
30
31### SAML 2.0 SSO Flow
32
33```
34User navigates to Google Workspace app (Gmail, Drive, etc.)
35 │
36 ├── Google checks: Is SSO configured for this domain?
37 │
38 ├── YES → Redirect user to IdP Sign-In Page URL
39 │ (SAML AuthnRequest sent via browser redirect)
40 │
41 ├── User authenticates at IdP (credentials + MFA)
42 │
43 ├── IdP generates SAML Response with signed assertion
44 │
45 ├── Browser POSTs SAML Response to Google ACS URL:
46 │ https://www.google.com/a/{domain}/acs
47 │
48 ├── Google validates SAML signature against uploaded certificate
49 │
50 └── User is granted access to Google Workspace
51```
52
53### Key SAML Parameters
54
55| Parameter | Value |
56|-----------|-------|
57| ACS URL | `https://www.google.com/a/{your-domain}/acs` |
58| Entity ID | `google.com/a/{your-domain}` or `google.com` |
59| NameID Format | `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` |
60| NameID Value | User's primary Google Workspace email |
61| Binding | HTTP-POST (for ACS), HTTP-Redirect (for SSO URL) |
62
63## Workflow
64
65### Step 1: Prepare the Identity Provider
66
67**For Okta:**
681. Navigate to Applications > Add Application > Search "Google Workspace"
692. Configure the Google Workspace app with your domain
703. Assign users/groups to the application
714. Download the IdP metadata or note: SSO URL, Entity ID, Certificate
72
73**For Azure AD (Microsoft Entra ID):**
741. Navigate to Enterprise Applications > New Application > Google Cloud/Workspace
752. Configure Single sign-on > SAML
763. Set Basic SAML Configuration:
77 - Identifier (Entity ID): `google.com`
78 - Reply URL (ACS): `https://www.google.com/a/{your-domain}/acs`
79 - Sign on URL: `https://www.google.com/a/{your-domain}/ServiceLogin`
804. Download Federation Metadata XML or Certificate (Base64)
81
82**For ADFS:**
831. Add Relying Party Trust using federation metadata
842. Configure claim rules to pass NameID as email address
853. Export the token-signing certificate
86
87### Step 2: Configure Google Workspace SSO
88
891. Sign in to Google Admin Console (admin.google.com) as Super Admin
902. Navigate to Security > Authentication > SSO with third-party IdP
913. Click "Add SSO profile" or configure the default profile
92
93**Third-Party SSO Profile Settings:**
94
95| Setting | Value |
96|---------|-------|
97| Set up SSO with third-party IdP | Enabled |
98| Sign-in page URL | IdP's SAML SSO endpoint (e.g., `https://idp.example.com/sso/saml`) |
99| Sign-out page URL | IdP's logout URL (e.g., `https://idp.example.com/slo`) |
100| Change password URL | IdP's password change URL |
101| Verification certificate | Upload IdP's X.509 signing certificate |
102| Use a domain-specific issuer | Enabled (uses `google.com/a/{domain}` as entity ID) |
103
104### Step 3: Assign SSO Profile to Users
105
106SSO profiles can be applied at different scopes:
107
108```
109Organization-wide (all users)
110 │
111 ├── Org Unit level (specific departments)
112 │ ├── Engineering OU → SSO via Okta
113 │ ├── Marketing OU → SSO via Azure AD
114 │ └── Contractors OU → SSO via specific IdP
115 │
116 └── Group level (specific security groups)
117 └── VPN Users → SSO with additional MFA
118```
119
1201. Navigate to Security > Authentication > SSO with third-party IdP
1212. Select the SSO profile to assign
1223. Choose organizational units or groups
1234. Save and wait for propagation (up to 24 hours, typically minutes)
124
125### Step 4: Configure Network Masks (Optional)
126
127Network masks control when SSO is enforced based on the user's IP:
128
129- If the user's IP matches a network mask, they use Google's sign-in page
130- If the user's IP does NOT match, they are redirected to the IdP
131
132This is useful for allowing direct Google login from corporate network while enforcing SSO for external access.
133
134### Step 5: Test SSO
135
1361. Open an incognito browser window
1372. Navigate to `https://mail.google.com/a/{your-domain}`
1383. Verify redirect to IdP sign-in page
1394. Authenticate at the IdP
1405. Verify successful redirect back to Google Workspace
1416. Test sign-out flow redirects to IdP logout page
1427. Test with user not assigned in IdP (should fail)
143
144## Validation Checklist
145
146- [ ] IdP SAML application configured with correct ACS URL and Entity ID
147- [ ] IdP signing certificate uploaded to Google Admin Console
148- [ ] SSO profile assigned to target organizational units/groups
149- [ ] SAML assertion includes correct NameID (email format)
150- [ ] MFA enforced at IdP for all Google Workspace users
151- [ ] Sign-out URL configured to terminate IdP session
152- [ ] Network masks configured if internal/external access differs
153- [ ] Break-glass Super Admin accounts bypass SSO (use Google auth)
154- [ ] SSO tested with multiple user types (admin, standard, contractor)
155- [ ] SAML response signature validated successfully
156- [ ] Error handling tested (expired cert, invalid user, clock skew)
157
158## References
159
160- [Google Workspace SSO Configuration Guide](https://support.google.com/a/answer/12032922)
161- [Set Up Custom SAML App - Google](https://support.google.com/a/answer/6087519)
162- [Okta Google Workspace SAML Guide](https://saml-doc.okta.com/SAML_Docs/How-to-Enable-SAML-2.0-in-Google-Apps.html)
163- [SAML 2.0 Technical Overview - OASIS](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)