SSO for a small business with Google Workspace or Entra ID

Single sign-on (SSO) lets your team sign in to business apps with the company account they already have in Google Workspace or Microsoft Entra ID. You get one identity per person, one password policy, and one place to switch access off when someone leaves.

For a small business the case is simpler than the enterprise pitch suggests. You already pay for an identity provider: the account that runs your email and calendar. Every app that accepts it is one less password to create, reset and remember to revoke.

How single sign-on works

Two parties are involved. The identity provider (Google Workspace, Entra ID or a dedicated identity service) knows who your people are and checks their password and second factor. The service provider is the business app they want to use. When someone signs in, the service sends them to the identity provider, which confirms who they are, and the service lets them in.

StandardWhat it isWhere you see it
SAML 2.0An XML-based standard for passing a signed sign-in statement from the identity provider to the serviceMany established business and enterprise apps
OpenID ConnectA sign-in layer built on OAuth 2.0 that passes a signed identity tokenMany newer web and mobile apps

Both Google Workspace and Entra ID can act as the identity provider for third-party apps over either standard. Which one you use depends on what the service supports. You do not need to understand the protocols in detail; you need the few values each side asks for, and a test account to try it with.

Why a small team should care

  • Leavers lose access in one step. Suspend the account in the identity provider and every connected app stops accepting new sign-ins with it.
  • One strong sign-in. Protect the identity provider with a second factor and that protection covers every app behind it. See two-factor authentication for small teams.
  • Fewer passwords to manage. New hires sign in with the account they already have.
  • A clearer record. The identity provider's sign-in log shows who signed in to what and when.
  • Consistent rules. Password length, second factors and session length are set once in the identity provider instead of app by app.

Setting it up: the usual steps

  1. Check what the service supports. SAML, OpenID Connect or both, and whether it works with your identity provider by name.
  2. Register the service with your identity provider. In Google Workspace a SAML app is added in the Admin console, and an OpenID Connect client in the Google Cloud console; in Entra ID it is an app registration or enterprise application. You get a client ID, a secret or certificate, and sign-in addresses to exchange with the service.
  3. Enter the details in the connected app. Paste the identity provider's values into its single sign-on settings, and copy its redirect address back into the identity provider.
  4. Limit it to your domain. Many apps let you restrict single sign-on to your company's email domain.
  5. Decide how accounts are created. Some apps create an account the moment a new person signs in; others expect accounts to be provisioned ahead of time, often with SCIM. The guide to SCIM provisioning explains the difference.
  6. Test with one person, then roll out to the rest of the team. Keep one administrator account outside single sign-on, so a problem at the identity provider does not lock everyone out.

What to check before you rely on it

  • Plan placement. Some vendors put single sign-on in a higher or enterprise plan. Price that plan from the start if you need it.
  • Roles still matter. Single sign-on decides who can get in, not what they can see. Roles and permissions inside each app still do that job; see field-level permissions in business apps.
  • Mobile and desktop apps. Ask whether single sign-on works in the vendor's iPhone, iPad and Mac apps as well as in the browser.
  • Support and recovery. Ask the vendor what happens if your identity provider is unavailable, and how an administrator signs in to fix it.
  • Apple devices. Signing in to Apple's own services with a work identity is a separate setup, done through Apple Business Manager; see Managed Apple Accounts and federated sign-in.

Frequently asked questions

Is single sign-on worth it for a team of five?

Often, yes, if you already use Google Workspace or Entra ID for email. The setup is a one-time task per app, and the payoff comes the day someone leaves and you switch off one account instead of several.

What is the difference between SAML and OpenID Connect?

Both let an identity provider vouch for a person to an app. SAML passes a signed XML statement and is common in established business software. OpenID Connect passes a signed token on top of OAuth 2.0 and is common in newer web and mobile apps. For a small team, the right one is whichever the service supports well.

Can I use a personal Gmail account for single sign-on?

Not in the business sense. Single sign-on for a company relies on accounts the company owns and controls in Google Workspace or Entra ID, so an administrator can suspend them. A personal account stays with the person.

Does single sign-on replace a second factor?

No. It moves the sign-in to one place. That place should have the strongest protection you can give it, including a second factor for every account.

Run your business on Apple.

Create your account on the web, then set up your workspace in the app on your iPhone, iPad or Mac.

Create your account

Keep reading

  1. Two-factor authentication and passkeys for small teams

    Two-factor authentication adds a second proof, such as a code or a security key, on top of a password. Passkeys replace the password with a key held on the device and resist phishing. Turn on the strongest option each business account offers, email and finance before the rest.

  2. SCIM provisioning explained: add and remove users

    SCIM is an open standard that lets your identity provider create, update and deactivate user accounts in other apps for you. Add someone in Google Workspace or Entra ID and their accounts appear; remove them and access goes too.

  3. Field-level permissions explained for small teams

    Field-level permissions control single fields inside a record, such as a credit limit or bank details, on top of the record access a role gives. Each field gets its own Read and Update switch per role.