--- title: "Single Sign-On for Business Apps: Google & Entra ID" slug: "single-sign-on-google-workspace-entra-id" published: "2026-07-21" updated: "2026-08-02" categories: - "Payload" tags: - "single sign-on" - "SSO" - "Google Workspace SSO" - "Microsoft Entra ID" - "OpenID Connect" - "Payload CMS" - "SCIM provisioning" - "just-in-time provisioning" - "identity mapping" - "offboarding automation" - "OIDC" - "enterprise SSO" llm-intent: "reference" audience-level: "intermediate" framework-versions: - "payload@2.x" - "next.js@15" - "openid-connect@1.0" - "oauth2.0" - "scim@2.0" - "saml@2.0" status: "stable" llm-purpose: "Single sign-on for business apps: use Google Workspace or Microsoft Entra ID to centralize auth, enable provisioning, and streamline offboarding—start now." llm-prereqs: - "Access to Google Workspace" - "Access to Microsoft Entra ID" - "Access to OpenID Connect (OIDC)" - "Access to OAuth 2.0" - "Access to Payload CMS" llm-outputs: - "Completed outcome: Single sign-on for business apps: use Google Workspace or Microsoft Entra ID to centralize auth, enable provisioning, and streamline offboarding—start now." --- **Summary Triples** - (Google Workspace, exposes, OpenID Connect (OIDC) login endpoints for 'Continue with Google' SSO using scopes openid email profile) - (Microsoft Entra ID, supports, OIDC and SAML SSO and can perform SCIM-based provisioning for automated create/update/deactivate) - (Payload CMS, should maintain, local user records (roles, permissions, brands, departments, audit history) separate from identity verification) - (Identity mapping, should link, IdP claims (sub, email, email_verified, externalId) to the application's local user identifier) - (Just-in-time provisioning, does, create a local user on first successful OIDC login when no existing user matches the mapped identifier) - (SCIM provisioning, enables, centralized user lifecycle management (create, update, deactivate) from IdP to the application for automated offboarding) - (Security validation, requires, ID token signature verification, issuer (iss) and audience (aud) checks, nonce/state handling, and TLS for endpoints) - (Offboarding, implemented by, deprovisioning at IdP with SCIM or disabling SSO; the application reacts by disabling local user access and preserving audit history) - (Testing, should use, a staging tenant, test accounts, and verification of token claims, JWK rotation, and SCIM responses before production rollout) ### {GOAL} Single sign-on for business apps: use Google Workspace or Microsoft Entra ID to centralize auth, enable provisioning, and streamline offboarding—start now. ### {PREREQS} - Access to Google Workspace - Access to Microsoft Entra ID - Access to OpenID Connect (OIDC) - Access to OAuth 2.0 - Access to Payload CMS ### {STEPS} 1. Understand SSO concepts and separation 2. Register the application with provider 3. Implement the OIDC login flow 4. Map identity to local user record 5. Enable just-in-time provisioning 6. Design offboarding and session handling 7. Test, secure, and deploy the integration # Single Sign-On for Business Apps: Google & Entra ID > Single sign-on for business apps: use Google Workspace or Microsoft Entra ID to centralize auth, enable provisioning, and streamline offboarding—start now. Matija Žiberna · 2026-07-21 Single sign-on lets employees open an internal application with the same company account they already use for email, documents, and meetings. A company running Google Workspace can offer "Continue with Google." A company running Microsoft 365 can use Microsoft Entra ID, formerly Azure Active Directory. Google or Microsoft verifies the employee's identity, and the application keeps its own local user record for roles, permissions, brands, departments, and audit history, then decides what that verified employee can actually do inside the app. I ran into this exact requirement while designing a multi-brand CMS and digital asset management platform. The client already managed every employee through Google Workspace, so this guide walks through how the identity check and the application's own access rules stay cleanly separated, and how to wire that separation into a Payload CMS user model. ## The problem with separate application accounts A new internal application often ships with its own users table, registration flow, password policy, reset process, and account-removal step. Employees end up remembering another password. Managers end up requesting accounts for new hires. Administrators end up disabling accounts by hand when people leave, and application owners end up fielding password-reset requests while maintaining their own authentication security. This workload multiplies once the application serves multiple brands, departments, agencies, and external partners. Single sign-on moves the initial identity check to the company's existing identity provider: | Company environment | Identity provider | | -------------------------------- | ---------------------------------- | | Google Workspace | Google Identity | | Microsoft 365 | Microsoft Entra ID | | Okta-managed environment | Okta | | Self-hosted enterprise identity | Keycloak or another OIDC provider | Google supports authentication through OpenID Connect and Google Identity Services. Microsoft Entra ID implements OpenID Connect on top of OAuth 2.0. Both systems issue a signed identity response that an application can validate before creating a local session. ## The basic SSO flow The login process runs through six steps. The employee opens the company application and selects "Continue with Google" or "Continue with Microsoft." Google or Microsoft authenticates the employee and returns a signed identity response. The application looks up or creates the corresponding local user, then starts its own session and applies its own access rules. The employee never creates a separate application password, and the application never receives the employee's Google or Microsoft password. The identity provider handles that exchange and hands back a limited set of verified identity claims: a stable provider identifier, email address, name, profile image, and Workspace domain or Microsoft tenant information. The application should store the stable provider identifier rather than relying on email alone. Email addresses get renamed or reused, while the provider identifier stays fixed to the account. ## Authentication and authorization remain separate SSO handles authentication: confirming this is a verified employee from the approved company account. The application handles authorization on top of that: deciding this employee can edit Brand A content, review Brand B assets, and view reports. A CMS or DAM might store a user record like this: ```ts { email: 'employee@company.com', identityProvider: 'google', identityKey: 'google:provider-user-id', roles: ['editor'], brands: ['brand-a'], departments: ['marketing'], active: true } ``` Google or Microsoft handles the employee's credentials, multifactor authentication, and company account status. The CMS or DAM handles admin access, editorial roles, asset permissions, brand access, approval rights, field-level restrictions, and audit relationships. Payload CMS supports authentication-enabled collections, custom authentication strategies, collection access control, field access control, and Admin Panel restrictions based on the authenticated user. ## Automatic user creation Many business applications use just-in-time provisioning, where the first successful company login triggers creation of the local application user: ```text Google or Microsoft verifies employee ↓ Application searches for identity key ↓ No application user exists ↓ Application creates a user with safe defaults ↓ Administrator assigns additional access ``` The default role should stay restrictive, with a new employee starting as a viewer or inactive user until an administrator assigns the correct brands and permissions. This removes the registration step while keeping access controlled from day one. ## Google Workspace and Microsoft Entra ID compared Both platforms support modern SSO, and their enterprise administration models differ in the details: | Area | Google Workspace | Microsoft Entra ID | | -------------------------- | -------------------------------------------- | ------------------------------------ | | Modern login protocol | OpenID Connect | OpenID Connect | | Application registration | Google Cloud Console | Entra App Registration | | Organisation restriction | Workspace domain and internal app settings | Tenant-specific application | | User administration | Google Admin console | Entra admin center | | Group-based access | Google Groups and Directory integration | Entra groups and application roles | | External collaborators | Separate account or Workspace policies | Entra guest users | | Advanced provisioning | Directory integration | SCIM and provisioning services | Google Workspace administrators can trust, restrict, or block which internal and third-party OAuth applications employees may access, and limit the Google data scopes those applications request. Microsoft Entra registers an application against a single tenant, so a tenant-specific authority ensures only members and permitted guests from the selected organisation can authenticate. ## SSO does not require access to company documents A login integration does not automatically grant access to Gmail, Google Drive, Outlook, SharePoint, or Microsoft Graph. The application can request only basic identity scopes: ```text openid email profile ``` Additional services require additional OAuth scopes and explicit approval. This separation matters during security review, since an internal CMS can confirm who the employee is without reading any Workspace documents or mail. Google allows administrators to configure access according to the exact OAuth scopes an application requests. ## Offboarding and account removal SSO improves offboarding because the employee's central company account controls their ability to authenticate again. Disabling a Google Workspace or Microsoft Entra account prevents the employee from completing a new login. The application still has to manage any session that already exists. A production design should include a limited session duration, an active flag on the local user, session revalidation, immediate application-level suspension, audit records, and optional directory synchronization. Larger organisations can automate this further with SCIM, which creates, updates, and deactivates application users based on the company directory. Basic SSO confirms identity at login, and directory provisioning keeps the local application user synchronized for the rest of the employee lifecycle. ## SSO for a CMS or DAM SSO earns its keep on internal content and asset platforms serving marketing teams, product teams, legal reviewers, designers, external agencies, regional offices, and administrators. The organisation already knows who these people are through Workspace or Entra ID, so the DAM can reuse that identity and layer application-specific access on top. A Google Workspace login could produce this mapping: ```text Verified Google Workspace employee ↓ Payload user ↓ Brand: CanPrev Role: Editor Department: Marketing ``` A Microsoft Entra environment could map an internal group to application access: ```text Entra group: Legal Reviewers ↓ Payload role: Approver Brand access: All brands ``` This keeps credentials centralized in one place while preserving granular application authorization. ## Custom implementation or enterprise SSO product Two implementation routes handle this well, depending on scale: | Route | Best fit | | --------------------------------- | ----------------------------------------------------------------------------------------- | | Custom OIDC integration | One or two known providers, controlled internal application, custom access model | | Vendor-supported enterprise SSO | Multiple providers, SAML requirements, formal support, strict procurement requirements | Payload sells an Enterprise SSO feature supporting SAML and OAuth 2.0 identity providers, including Google, Microsoft, and Okta, with automatic profile generation and permission mapping. The open-source version supports custom authentication strategies, so a development team can implement Google Workspace or Microsoft Entra authentication directly, taking on security, testing, upgrades, and long-term maintenance as part of the build. ## When SSO creates the most value SSO pays off once an application has more than a small number of internal users, regular employee onboarding and offboarding, multiple departments or brands, sensitive business information, company-wide multifactor authentication, external agencies or guests, formal security review, or granular roles and approvals. A public customer application may still need separate customer authentication, while an internal CMS, DAM, portal, knowledge system, or workflow application is usually a strong SSO candidate. ## FAQ ### Does SSO remove the application's users collection? No. The application still needs local users for roles, permissions, relationships, preferences, and audit history. SSO replaces the separate application password. ### Does the application receive the employee's Google or Microsoft password? No. The employee authenticates directly with Google or Microsoft, and the application receives a signed identity response. ### Can any personal Google or Microsoft account log in? The application should restrict access to the approved Workspace domain or Microsoft Entra tenant. Company administrators can also restrict which applications employees are allowed to use. ### Does SSO automatically remove a user when they leave? It prevents future authentication once the company account is disabled. Existing application sessions and local user status still need explicit handling, which SCIM or directory synchronization can automate. ### Is SSO only available to enterprise companies? The protocols are open and broadly available. Enterprise products package provider support, configuration, maintenance, and vendor accountability on top of that. Smaller teams can build a focused OpenID Connect integration for their own applications. ## Conclusion Single sign-on creates a cleaner employee experience and a stronger access-control model for business applications. Google Workspace and Microsoft Entra ID already manage employee identities, and a CMS, DAM, internal portal, or workflow application can reuse that identity while keeping its own roles and permissions: ```text Google or Microsoft Identity and company authentication Payload CMS or business application Roles, permissions, brands and access control ``` This split removes duplicated passwords, improves onboarding, centralizes authentication policy, and gives internal applications a more credible enterprise security model. I design Next.js and Payload CMS platforms for organisations managing multiple brands, teams, workflows, and business systems. Let me know in the comments if you have questions, and subscribe for more practical development guides. Thanks, Matija ## LLM Response Snippet ```json { "goal": "Single sign-on for business apps: use Google Workspace or Microsoft Entra ID to centralize auth, enable provisioning, and streamline offboarding—start now.", "responses": [ { "question": "What does the article \"Single Sign-On for Business Apps: Google & Entra ID\" cover?", "answer": "Single sign-on for business apps: use Google Workspace or Microsoft Entra ID to centralize auth, enable provisioning, and streamline offboarding—start now." } ] } ```