How to set up SSO with Microsoft Entra ID and Google Workspace using SAML 2.0 and OpenID Connect

To set up SSO with Microsoft Entra ID and Google Workspace, whether one directory or both, you do not integrate every application with every identity provider: you put an identity broker in the middle. Applications speak a single protocol — OpenID Connect — to the broker; the broker speaks SAML 2.0 or OIDC to Entra ID and Google Workspace. A new application then needs one configuration (redirect URI and project key) instead of N SAML configurations, and adding a new identity provider does not touch the code of applications already in production. With LoginMaster as the broker, applications connect through the TypeScript and .NET SDKs or the REST API (LoginMaster is not a generic OpenID Provider for your apps), and the broker federates Entra ID and Google Workspace over OAuth 2.0 / OpenID Connect; SAML 2.0 federation is on the roadmap.

OIDC or SAML 2.0: which one, and where

The question "SAML or OIDC?" has different answers depending on which side of the integration you are on. Between your applications and the broker, OIDC is almost always preferable: it is JSON, it works with SPAs and mobile apps, it handles token refresh and it does not require parsing and validating signed XML. Between the broker and the corporate identity provider the IdP decides: Entra ID and Google Workspace support both, but many established enterprise setups (and on-premise ADFS) only expose SAML 2.0. A clarification about LoginMaster: towards applications it does not expose a generic OpenID Connect endpoint, integration goes through the SDKs or the REST API; towards Entra ID and Google Workspace it federates over OIDC today, while SAML 2.0 is on the roadmap. The SAML steps below therefore apply to brokers that already support it.

For the theoretical comparison between the protocols, the extended treatment is in OAuth 2.0, OIDC and SAML: differences and use cases. Here we move on to configuration.

Step 1 — Register the application as a project

Every application that delegates login is a project: web app, mobile app and admin panel are three distinct projects, each with its own cryptographic key and its own policies. That is what lets you enforce mandatory 2FA on the admin panel while keeping it optional on the public app, without duplicating the user base.

1. 1Create the project in the tenant and note the project key (pk_live_…): it is the public identifier used in authentication calls.
2. 2Register the exact redirect URIs, one per environment. The comparison is character by character: https://app.example.com/callback and https://app.example.com/callback/ are two different URIs.
3. 3Set the project session lifetime and 2FA policy (disabled, optional, mandatory).
4. 4Generate a separate API key (ak_live_…) if the backend will also do provisioning: the project key is for login, the API key for administrative operations.

npm install @loginmaster/sdk

import { LoginMaster } from "@loginmaster/sdk";

const lm = new LoginMaster({
  projectKey: process.env.LOGINMASTER_PROJECT_KEY,
  tenant: "https://tenant.example.com",
});

// After delegated login: verify the dual-signature token (tenant + cloud)
const session = await lm.verifyToken(token);
if (session.valid) {
  const userId = session.subject; // e.g. sub_9f2a7c
}

The same applies on .NET with the ASP.NET Core middleware; both full quickstarts are on Integration. If you use neither TypeScript nor .NET, the same operations are available over REST: POST /v1/auth/token and POST /v1/auth/verify.

Step 2 — Federate Microsoft Entra ID via OpenID Connect

This is the path to prefer with Entra ID when there are no historical constraints. In the Entra ID portal: App registrations → New registration.

1. 1Supported account types: choose "Accounts in this organizational directory only" for a closed corporate SSO, or multitenant if you must accept several customer directories.
2. 2Redirect URI (Web type): the broker callback endpoint, not the one of the final application.
3. 3Certificates & secrets: generate a client secret (or better, register a certificate) and store it in the broker tenant.
4. 4API permissions: openid, profile, email. Add User.Read only if you need to read the Graph profile; SSO alone does not require it.
5. 5Token configuration: add the groups claim if you want to map Entra groups onto application roles.

https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration

From that document the broker automatically derives the authorization endpoint, the token endpoint and the jwks_uri, so Microsoft's signing key rotation requires no manual work. The relevant ID token claims are:

Step 3 — Federate Microsoft Entra ID via SAML 2.0

You need this when the organisation has already standardised on SAML or when the IdP is on-premise ADFS. In the portal: Enterprise applications → New application → Create your own application → Integrate any other application, then Single sign-on → SAML.

Then download the Federation Metadata XML and upload it to the broker: it contains the IdP EntityID, the SSO endpoints and the signing certificate, and importing it avoids transcribing the certificate by hand.

https://login.microsoftonline.com/{tenantId}/federationmetadata/2007-06/federationmetadata.xml

The same rule as the oid claim applies to the NameID: set user.objectid with persistent format. The Entra ID default is often the email address, and it is the number-one cause of duplicate accounts after a corporate reorganisation.

Signing certificate rotation

Entra ID SAML certificates default to a three-year validity, and expiry breaks login for every user at the same instant. Two concrete countermeasures: configure expiry notifications to a monitored mailbox, and import the IdP metadata by URL rather than as a file, so the broker re-reads the certificate without a manual task scheduled three years in advance.

Step 4 — Federate Google Workspace via OpenID Connect

Google exposes a public discovery document and a single issuer for all domains, so configuration is shorter than Entra ID's — but with one extra security requirement.

https://accounts.google.com/.well-known/openid-configuration

1. 1In Google Cloud Console create a project and, under APIs & Services → Credentials, an OAuth 2.0 Client ID of type Web application.
2. 2Authorized redirect URIs: the broker callback endpoint (exact, https, no trailing slash unless you use one).
3. 3Configure the OAuth consent screen as Internal if you want to restrict it to the Workspace domain only.
4. 4Requested scopes: openid, email, profile.
5. 5Validate the hd (hosted domain) claim on every login on the broker side: without that check, any personal Gmail account going through the same consent screen is technically a valid login.

Step 5 — Federate Google Workspace via SAML 2.0

In the Admin console: Apps → Web and mobile apps → Add app → Add custom SAML app. Google shows its own metadata (SSO URL, Entity ID, certificate) to upload to the broker; then you fill in the Service Provider ACS URL and Entity ID.

1. 1Copy or download Google's IdP metadata and import it into the broker.
2. 2Service provider details: broker ACS URL and Entity ID; Name ID format PERSISTENT and Name ID = Basic Information > Primary email (or a custom immutable attribute, if you manage one).
3. 3Attribute mapping: map at least primary email, first name, last name; add groups if you need them for roles.
4. 4User access: assign the app to the organisational units or groups that must have access. Skip this and login fails with app_not_configured_for_user.
5. 5Allow for propagation: Admin console changes can take several minutes to become effective for all users.

Step 6 — Map claims and groups onto application roles

The real value of federated SSO is not saving a password: it is that authorisation stops living in a local table nobody updates. A user who moves department changes group in the directory, and the application role follows at the next login with no IT ticket.

Two rules that prevent incidents: always assign a minimal baseline role to anyone who authenticates but matches no rule (instead of inheriting the last known role), and recompute roles at every login rather than only at account creation. The second point is what makes privilege revocation effective, not just access revocation.

If there are many groups to propagate, note that Entra ID "overages" the token beyond a certain group count and returns a Graph reference instead of the list: in that case, map explicit app roles rather than raw groups.

Step 7 — Session, revocation and deprovisioning

SSO is half the problem; the other half is what happens when access must stop. With federation, disabling the account in the corporate directory stops new sessions being issued on federated services: you do not have to remember to disable the user on every platform. The residual window is the lifetime of tokens already issued, which is why it should be sized deliberately.

With a broker that supports them, the lever for immediate revocation is the webhook: the broker notifies the application and the application invalidates its own session, with no polling. In LoginMaster lifecycle webhooks are on the roadmap and not available today: immediate revocation relies on a short token lifetime and on verifying the dual-signature token on every sensitive request. Mind a second limit too: deactivating a subject blocks new logins but does not atomically revoke sessions and API keys, which must be closed with explicit steps.

The full lifecycle (creation, role change, suspension, deletion) is covered in User provisioning and lifecycle via REST API and SDK.

Entra ID and Google Workspace together: one SSO for both directories

Many organisations run both: Microsoft 365 and Entra ID for one business unit, Google Workspace for another, often after an acquisition or a merger. There are two different problems here, and it pays to keep them apart.

1. Signing in to Google Workspace with Entra ID credentials. Here Entra ID is the identity provider and Google Workspace is the service provider. Microsoft publishes a native gallery application ("Google Cloud / G Suite Connector by Microsoft") for this. It is configured between Microsoft and Google and does not involve your own applications.

2. Letting users from both directories into your own business applications. This is the scenario this guide covers. Instead of configuring every application twice, you register Entra ID (Steps 2–3) and Google Workspace (Steps 4–5) as two identity providers on the same broker. Your applications keep speaking one protocol, OpenID Connect, and the broker tells the two populations apart through the tid claim (Entra ID) and the hd claim (Google Workspace).

Two rules apply when both directories are federated:

• Correlate users on immutable identifiers (oid for Entra ID, sub for Google), never on email. The same person may have an address in both directories, and correlating on email merges two distinct accounts.
• Map roles per source. An Entra ID group and a Google Workspace group with the same name are not the same group. Keep separate mapping rules for each identity provider (see Step 6).

Testing: nine checks before release

1. 1SP-initiated login: from the application, with the user not yet authenticated at the IdP.
2. 2IdP-initiated login: from the Microsoft or Google portal (SAML only; it does not exist in OIDC, and asking for it signals a mis-stated requirement).
3. 3Valid user not assigned to the application: it must fail with an understandable message, not a blank page.
4. 4User from an external domain: must be rejected (hd or tid claim verification).
5. 5Expired session: silent renewal and, where impossible, a clean return to the login screen.
6. 6Logout: check whether the IdP session stays open; with partial SLO the user 'leaves' and re-enters with one click, and that must be documented.
7. 7Account disabled in the IdP: new login refused within the expected time.
8. 8Clock skew: move a client clock by 10 minutes and check the error message (SAML will fail on the NotBefore / NotOnOrAfter conditions).
9. 9Signing certificate rotation: simulate it in a test environment, do not discover it in production.

Typical errors and how to read them

Managed broker, self-hosting or direct integration

All three routes are viable, but their cost and risk profiles differ sharply. The honest comparison is about the work left after the first successful login.

What sets LoginMaster apart in the bottom rows is not commercial but architectural: the token returned to the application carries two independent signatures, one from the tenant and one from the cloud, and a token issued for tenant A fails validation in the context of tenant B even when the two share the deployment. Architecture details are on Security, while the SSO page collects the available federation features. Teams coming from a Keycloak installation will find the full path in Migrating from self-hosted Keycloak to a managed IAM.

Where this guide comes from

LoginMaster is the IAM platform of CDBKR S.r.l., an Italian company that builds and operates authentication infrastructure for software houses, MSPs and European enterprise organisations. The procedures described here are the ones the team applies in federation projects towards Entra ID and Google Workspace, including the case where both directories coexist in the same organisation. A real adoption example is documented in the case studies; to assess your own scenario, start from the contact page.