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.
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:
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.
