# EASIE SSO: What It Is and Which Providers Support It **What is EASIE SSO, and which providers support it?** EASIE SSO is a way to deliver enterprise [single sign-on](https://clerk.com/glossary.md#single-sign-on-sso) over [OpenID Connect](https://clerk.com/glossary.md#openid-connect): an application offers "Sign in with Google" or "Sign in with Microsoft" as managed, organization-wide SSO, enrolling each enterprise by its email domain against a multi-tenant identity provider with no per-customer metadata, certificates, or secrets to exchange. Two identity providers support it (Google Workspace and Microsoft Entra ID). Clerk created the open specification, published at [easie.dev](https://easie.dev/), and implements it alongside SAML and OIDC ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)); other vendors have since adopted it, including [Ours Privacy](https://docs.oursprivacy.com/docs/enterprise-single-sign-on). As of June 2026, based on the linked provider documentation, those are the publicly documented implementations. Designed for IT admins, developers, and technical decision-makers evaluating enterprise SSO options, this guide explains what EASIE is, how it works, supported providers, and how it compares to SAML and SCIM. It requires only a basic familiarity with OAuth and SAML, rather than expert-level knowledge. One scope note up front: EASIE handles authentication, just-in-time account creation, and reactive deprovisioning. It is not a directory-sync (SCIM) replacement, so it doesn't continuously mirror your full user directory. The sections below explain where that line falls and why it matters. ## What Is EASIE SSO? EASIE SSO is enterprise single sign-on built on OpenID Connect, where a company is identified by its email domain and authenticated through a multi-tenant identity provider it already uses (today, Google or Microsoft) without exchanging any per-customer credentials. It closes the gap between a casual "Sign in with Google" button and a full SAML integration: organization-wide, admin-mandated sign-in with just-in-time provisioning, but none of SAML's metadata and certificate plumbing. Two definitions make the rest of this article unambiguous. A **multi-tenant OIDC provider** is a single OpenID Connect identity provider whose one shared issuer serves many organizations at once. Google's `accounts.google.com` issuer authenticates every Google Workspace tenant; Microsoft's `/common` endpoint serves every Entra tenant. Each request is tagged with a claim that says which organization the user belongs to (`hd` for Google, `tid` for Microsoft). That is different from a **single-tenant IdP** like Okta or Ping, where each customer gets its own issuer, endpoints, and credentials. EASIE is possible only because Google and Microsoft each run a multi-tenant OIDC provider, so one application registration can serve all of their customer organizations. The general pattern of one system serving many isolated tenants is [multi-tenancy](https://clerk.com/glossary.md#multi-tenancy). EASIE also involves **three parties**, and "configuration" means something different for each. The **application** (the vendor implementing EASIE) configures its own Google or Microsoft OAuth credentials once per provider, then reuses them across every connection. The **enterprise customer** exchanges no per-connection secrets at all: no metadata file, no certificate, no one-off client secret. The **end users** on the enrolled domain are forced through the IdP and provisioned on first sign-in. So the precise claim throughout this article is "zero per-customer credential exchange," not "zero configuration." ### A Plain-English Definition EASIE is enterprise SSO delivered over OIDC using the identity providers enterprises already run: Google Workspace and Microsoft Entra ID. The enterprise is identified by its email domain. Once that domain is enrolled, every user on it is forced through the chosen IdP on sign-in. There are no per-customer metadata files, certificates, or shared secrets to swap, because the IdP is multi-tenant and one shared issuer covers all of its tenants ([easie.dev](https://easie.dev/)). The application owner still sets up app-level provider credentials once in production, which is why the accurate phrasing is "zero per-customer credential exchange." Three properties are what make EASIE "enterprise" rather than a social button: sign-in is admin-mandated and forced, it is scoped to the organization, and accounts are created (and later revoked) automatically. And one boundary, stated early so it doesn't get lost: EASIE is not a directory-sync (SCIM) replacement. It authenticates, creates accounts just in time, and reacts to deprovisioning, but it does not continuously sync your directory ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). The SCIM distinction gets its own section below. ### Where the Term Comes From: the EASIE Spec EASIE is an open specification published at [easie.dev](https://easie.dev/) and created by Clerk. The spec is explicit about its origin: "The EASIE SSO specification was created by Clerk, which builds developer tools for authentication." It was last updated 2024-11-20, lists `easie@clerk.dev` as its security contact, and describes itself as "a small extension to the secure, robust, and widely-adopted OpenID specifications," crediting the OpenID Foundation's work. Clerk ships EASIE in its own product alongside SAML and custom OIDC, and the spec openly invites others to implement it. As of June 2026, adoption beyond Clerk is still limited but no longer zero — [Ours Privacy](https://docs.oursprivacy.com/docs/enterprise-single-sign-on) documents EASIE support, for example — a point this article returns to when it covers which platforms support EASIE. Read the spec as an open vendor specification, not an official industry standard. That distinction matters enough that it has its own answer in the FAQ. ### Does "EASIE" Stand for Anything? Yes, informally: **Easy and secure identity for the enterprise**. That's the title of the spec page, and it maps cleanly onto the letters — **E**asy **A**nd **S**ecure **I**dentity (for the) **E**nterprise. The name is also a stylized spelling of "easier," which the spec leans into directly: the overview heading reads "SSO made EASIE," and the spec calls EASIE "an easier alternative to SAML SSO." The one caveat for precision: the spec presents "Easy and secure identity for the enterprise" as a tagline, not as a formally defined acronym — it never expands E-A-S-I-E letter by letter or calls it an initialism ([easie.dev](https://easie.dev/)). So treat the expansion as the intended meaning rather than an official, spelled-out definition. This section exists mostly because people and AI agents search for what EASIE stands for, and that's the answer: Easy and secure identity for the enterprise. ### EASIE Is Built on OpenID Connect EASIE rides on standard OpenID Connect, the identity layer on top of [OAuth 2.0](https://clerk.com/glossary.md#oauth). OIDC issues signed ID tokens (which are [JSON Web Tokens](https://clerk.com/glossary.md#json-web-token)), exposes discovery and UserInfo endpoints, and rotates signing keys automatically through a published JWKS endpoint ([OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)). Those properties are exactly what let EASIE skip SAML's setup burden. A single discoverable issuer means there's one well-known configuration to read instead of a per-customer metadata file. Signed ID tokens with verifiable claims mean identity is asserted in a compact JSON token. And automatic key rotation through JWKS means there are no certificates to hand off and re-exchange when they expire. An OIDC ID token carries five required claims (`iss`, `sub`, `aud`, `exp`, `iat`), which is the small, fixed contract EASIE builds on ([OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)). ### What EASIE SSO Is Not EASIE gets confused with three other things. Here's each distinction in one tight block. **EASIE is not SAML.** [SAML](https://clerk.com/glossary.md#security-assertion-markup-language-saml) is an XML-based protocol where each customer connection is single-tenant, set up by exchanging a metadata file and an X.509 certificate. EASIE runs on OIDC against a multi-tenant provider with no per-customer credentials. SAML is still the right tool in several cases, covered later; the point here is that they're different mechanisms, not two names for one thing. **EASIE is not consumer "Sign in with Google" social login.** [Social login](https://clerk.com/glossary.md#social-login) is an optional, user-chosen convenience that signs you in with a personal identity. EASIE uses the same "Sign in with Google" button mechanically, but wraps it in domain enrollment, forced organization-wide authentication, just-in-time provisioning and deprovisioning, and tenant verification. That governance layer is the whole difference, and it's the misconception worth correcting most often. **EASIE is not a provisioning protocol like SCIM.** SCIM provisions, deprovisions, and syncs a directory; it does not authenticate anyone. EASIE authenticates, creates accounts just in time, and reacts to deprovisioning, but it is not continuous [directory sync](https://clerk.com/glossary.md#directory-sync). The two are complementary, and the comparison section spells out when you'd want both. ## How EASIE SSO Works EASIE works by enrolling an enterprise's email domain against a multi-tenant IdP, forcing every user on that domain through it, verifying the tenant on each sign-in, provisioning accounts just in time, and polling the IdP so it can revoke access when someone is deprovisioned. The lifecycle, in order: 1. Enroll the enterprise's email domain and record which multi-tenant IdP it uses (Google or Microsoft). 2. Force every user on that domain (new and existing) through that IdP on sign-in. 3. Verify the tenant claim on each sign-in so a user from one organization can't land in another. 4. Provision an account just in time the first time a domain user signs in. 5. Poll the IdP while the user is active, and revoke their sessions when they're deprovisioned. Each step maps to one of the five requirements in the EASIE spec, so the rest of this section walks them in that order. ### Built on OpenID Connect EASIE "works primarily over OpenID Connect endpoints," which buys it the standard authorization-code flow (with PKCE), signed ID tokens, discovery, and JWKS key rotation, all without a certificate exchange ([easie.dev](https://easie.dev/)). The [authorization code flow](https://clerk.com/glossary.md#authorization-code-flow) is the same browser-redirect pattern enterprises already use for Google and Microsoft sign-in, so there's nothing exotic to stand up. This is the foundation the other four requirements build on. ### Email Domain-Based Enrollment A connection is keyed to an enterprise's email domain plus its chosen IdP. The spec's first requirement, "Initial setup," says the application "MUST accurately verify" two things: "the email domain used by the enterprise" and "the multi-tenant IdP used by the enterprise" ([easie.dev](https://easie.dev/)). In practice that verification happens with an authorized party (usually IT) or, for self-serve flows, through a domain-control challenge similar to issuing a TLS certificate. Compare that to a SAML or per-customer OIDC connection, where setup means swapping a metadata file or a client secret for every customer. EASIE's setup is "which domain, which IdP," and the credential side is handled once at the application level. ### Just-in-Time Provisioning and Deprovisioning EASIE creates accounts just in time and reacts to deprovisioning by polling the IdP, rather than syncing a directory. The spec's second requirement, "Account provisioning," says accounts "MUST be provisioned just-in-time, when a user with the email domain is seen for the first time," and that "Resource access is out of scope for EASIE SSO" ([easie.dev](https://easie.dev/)). There's no bulk or proactive import; the first sign-in from a domain user creates the account. The fifth requirement, "Automatic deprovisioning and session revocation," handles the exit. Because OIDC has no native deprovisioning signal, the application polls the IdP's user-profile endpoints while a user is active. The spec's MUST-language attaches a deadline to detection, not to the polling cadence: "If a user is actively visiting the application, the application MUST detect deprovisioning within 10 minutes of the deprovisioning occurring, then must revoke their sessions immediately" ([easie.dev](https://easie.dev/)). For Google that detection looks like a UserInfo request that starts returning an error; for Microsoft it's a Graph check where `accountEnabled` flips to `false`. The nuance to hold onto: this is reactive, poll-then-revoke behavior, not a SCIM push. It closes plain just-in-time provisioning's biggest gap, which is that a former employee keeps access indefinitely. But it is still not full directory sync, and the SCIM section returns to that. ### Forced Authentication Through the Identity Provider Once a domain is enrolled, EASIE forces every user on it through the IdP, and the application blocks the usual bypass paths. The spec's third requirement, "Forcing SSO," states: "After a domain is enrolled in EASIE SSO, the application MUST force all users with that email domain (new or existing) to authenticate through the enterprise's choice of multi-tenant IdP." If a user tries another method, "they should either be forwarded directly to the multi-tenant IdP, or they should receive an error directing them there" ([easie.dev](https://easie.dev/)). That forcing behavior is what separates EASIE from an optional social button. Existing users whose email matches the enrolled domain get linked to the enterprise connection, password verification is bypassed in favor of the IdP, and bypass routes (resetting a password, adding a second non-enterprise email, signing in with a different provider) are closed off. In Clerk specifically, that linking behavior depends on having "Verify at sign-up" enabled, so accounts are matched on a verified email ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/account-linking.md)). ### The Core Design Choice: Multi-Tenant Identity Providers The single design decision that makes EASIE simple is that it depends on a multi-tenant identity provider, where one shared issuer serves every organization, instead of a single-tenant IdP that issues per-customer credentials. **Why multi-tenancy removes the setup burden.** The spec puts it plainly: "EASIE SSO depends on a multi-tenant identity provider, while traditional SSO depends on a single-tenant identity provider" ([easie.dev](https://easie.dev/)). Google runs one issuer, `accounts.google.com`, for every Workspace tenant, and stamps each token with an `hd` claim naming the organization. Microsoft's `/common` endpoint serves every Entra tenant and "isn't a tenant or an issuer itself"; it discovers the user's tenant at sign-in and stamps the token with that tenant's `tid` ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity-platform/howto-convert-app-to-be-multi-tenant)). Because one app registration covers all of a provider's customer organizations, there's "no need to share credentials, like a one-off OIDC client secret or SAML metadata file" ([easie.dev](https://easie.dev/)). Single-tenant IdPs (Okta, Ping, and the like) give each customer its own issuer and credentials, so there's no shared endpoint to enroll a domain against. **The tenant-isolation trade-off to understand.** Leaning on a shared provider has a cost the spec names directly: "Relying on a multi-tenant provider increases the risk that a user from one tenant will mistakenly be granted access to the resources of another tenant" ([easie.dev](https://easie.dev/)). That's tenant crossover, and the spec's fourth requirement is the mitigation: verify the user actually came through the correct tenant. For Google, "Verify that the `hd` claim in the OIDC ID token matches the enterprise email domain." For Microsoft, "Verify that the `xms_edov` claim in the OIDC ID token is set to true" ([easie.dev](https://easie.dev/)). The check is provider-specific, not standardized across IdPs. Here's an illustrative decoded ID-token payload (Google-style) showing the claims an EASIE implementation reads: ```json { "iss": "https://accounts.google.com", "aud": "your-app.apps.googleusercontent.com", "sub": "112233445566778899001", "email": "dana@acme.example", "email_verified": true, "hd": "acme.example" } ``` Those are fake values, and the snippet is a decoded payload, not a verification recipe. Before trusting any of it, a production application must validate the token's signature against the provider's published keys, confirm `iss` and `aud` are what it expects, check `exp` (plus `nonce` and `state` where applicable), and then verify the tenant signal: that `hd` equals the enrolled domain for Google, or that `xms_edov` is `true` for Microsoft. It must also key the user on the stable identifier, `sub` for Google or `oid` plus `tid` for Microsoft, and never on the mutable `email` claim ([Google OIDC docs](https://developers.google.com/identity/openid-connect/openid-connect); [Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference)). The security FAQ explains why the `email` claim is the wrong key and which real-world OIDC weaknesses these checks defend against. ## Which Providers Support EASIE SSO As of June 2026, EASIE SSO works with two identity providers, Google (Google Workspace) and Microsoft (Entra ID), and Clerk — which authored the spec — is its primary implementation, though no longer the only one. This section uses "provider" in two senses, kept separate here: **identity providers** are the IdPs that can power EASIE (today, Google and Microsoft), and **authentication platforms** are the products that implement EASIE for applications (Clerk, with early adoption by others such as Ours Privacy). The two get their own tables at the end of the section. One more yardstick to state before naming any platform: what counts as an EASIE equivalent. A true equivalent needs all five of these: (1) a multi-tenant OIDC IdP, one shared issuer for many tenants; (2) email-domain enrollment, not just routing; (3) mandatory, organization-scoped (forced) authentication; (4) just-in-time provisioning plus automatic deprovisioning; and (5) no per-customer credentials (no per-tenant SAML metadata, certificate, or OIDC client secret). That's the test applied later when this article assesses which platforms offer an equivalent. ### Identity Providers Supported Today EASIE supports identity providers that operate a multi-tenant OIDC service. Today that means Google and Microsoft. The spec's "Future plans" section mentions adding more workforce identity providers but names no confirmed dates or candidates ([easie.dev](https://easie.dev/)). #### Google (Google Workspace) Google works as an EASIE IdP through standard "Sign in with Google." Google operates one shared OIDC issuer, `accounts.google.com`, for every Workspace organization, which makes it multi-tenant. The token's `hd` (hosted domain) claim identifies the organization. In Google's own words, `hd` is "the domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization," so its absence signals a consumer Gmail account rather than a managed domain ([Google OIDC docs](https://developers.google.com/identity/openid-connect/openid-connect)). The token also carries `email_verified`, and the stable key is `sub`, which Google describes as "unique among all Google Accounts and never reused" with the explicit instruction to "always use the `sub` field" rather than email as the identifier. On availability, this is the part that surprises people: because EASIE uses Google as the identity provider (the application authenticates the user to Google), it works for any Google Workspace account regardless of edition, and it requires no Workspace admin to "turn on SSO." There is no Google Workspace paid tier to buy and no inbound-SSO product to configure for a customer to sign into an EASIE app via Google OIDC. An admin can optionally restrict which third-party OAuth apps are allowed in their tenant, but that's an opt-in restriction, not a required enablement step. > Don't confuse this with Google's "Custom OpenID Connect (OIDC) SSO profiles," which went generally available 2025-11-18. That feature makes Google the service provider, so employees sign into Google Workspace through a third-party IdP. That's the opposite direction from EASIE, and its edition and admin gating have nothing to do with EASIE's availability ([Google Workspace Updates, Nov 2025](https://workspaceupdates.googleblog.com/2025/11/single-sign-on-with-custom-openid.html)). Two caveats worth keeping in mind. First, `hd` is a conditional claim: it isn't advertised in Google's published `claims_supported` list, so an implementation has to confirm it's present and that it matches the enrolled domain, rather than assuming it. Second, on setup, the application (or Clerk in production) supplies a Google OAuth client ID, secret, and redirect URI once, and the enterprise customer configures nothing: no Workspace SSO profile, no metadata, no per-customer secret. Clerk development instances use shared credentials, and an existing Google social connection's credentials are reused if you already have one ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/easie/google.md)). #### Microsoft (Entra ID, formerly Azure AD) Microsoft works as an EASIE IdP through a multi-tenant Entra app registration. The vendor registers one application as "Accounts in any organizational directory and personal Microsoft accounts" and sends sign-in to the shared `/common` endpoint, which "isn't a tenant or an issuer itself." The first user from a new tenant triggers admin consent, which creates a service principal in that customer's tenant; the token issuer then carries the user's `tid`. Implementations validate that the token's issuer matches the user's tenant and key users on the stable identifier ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity-platform/howto-convert-app-to-be-multi-tenant)). For Microsoft, `sub` is pairwise (per-application), while `oid` is stable for a user across applications, so a platform that needs cross-app correlation keys on `oid` plus `tid` ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference)). On security, Microsoft's `email` claim is mutable, and Microsoft's own guidance is blunt: "Never use it for authorization or to save data for a user." The `xms_edov` claim is a boolean indicating "whether the user's email domain owner has been verified" ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims-reference)). EASIE requires verifying it precisely to close the nOAuth account-takeover class covered in the security FAQ below. On tiers, the load-bearing fact is short: Entra Free is enough. Microsoft's pricing page lists "unlimited SSO across any SaaS app" on the Free tier, so no paid Entra plan is required for EASIE sign-in. Paid tiers (P1 at roughly $6/user/month and P2 at roughly $9/user/month, on annual commitment) add policy and security features like Conditional Access, Identity Protection, and PIM, not the OIDC sign-in itself ([Microsoft Entra pricing](https://www.microsoft.com/en-us/security/business/microsoft-entra-pricing)). Those prices change, so verify them at the source. One setup caveat is specific to Microsoft: the multi-tenant registration and the `xms_edov` optional claim are configured once by the vendor, and Microsoft caps client secret lifetime at 24 months (it recommends under 12). In production those secrets are platform-rotated rather than handled per customer ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity-platform/how-to-add-credentials)). #### Practical Notes and Caveats Per Provider A scannable summary of what's specific to each IdP: - **Google:** any Workspace edition works; no admin "enable SSO" step; `hd` is conditional, so verify it's present and matches the enrolled domain; reuse an existing Google social connection's credentials in production. - **Microsoft:** Entra Free is sufficient; register a multi-tenant app and enable the `xms_edov` optional claim; first sign-in from a new tenant needs admin consent; client secrets expire within 24 months and need rotation. - **Both:** identify users by the immutable identifier (`sub` for Google, `oid` plus `tid` for Microsoft), verify the tenant claim (`hd` or `xms_edov`), and never trust the raw `email` claim for identity or authorization ([Google OIDC docs](https://developers.google.com/identity/openid-connect/openid-connect); [Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity-platform/claims-validation)). ### What About Okta, Ping, and Other IdPs? They can't act as EASIE identity providers, because they're single-tenant per customer. Each Okta, Ping, OneLogin, or JumpCloud customer gets its own issuer, endpoints, and credentials, so there's no shared multi-tenant endpoint to enroll a domain against. The spec says so directly, noting that EASIE is "limited to solutions that offer a multi-tenant OIDC provider, and this currently excludes many popular providers, including Okta and Rippling" ([easie.dev](https://easie.dev/)). This is not "Clerk can't do Okta." Okta, Ping, and the rest remain fully usable for enterprise SSO through traditional per-connection SAML or custom OIDC. They just don't fit EASIE's zero-credential, domain-enrollment model. If your customer's IdP is one of these, the answer is SAML or custom OIDC, not "no SSO." ### Authentication Platforms That Implement EASIE Clerk is the platform that authored and implements EASIE, offering it alongside SAML and custom OIDC as its three enterprise-connection types ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). The full Clerk treatment is later in this article; the question here is whether anyone else implements it. First, a distinction that trips people up: domain **routing** versus domain **enrollment**. Domain routing (also called home-realm discovery or identifier-first sign-in) uses a user's email domain only to select a connection the customer's IT already configured, a per-customer SAML or OIDC connection with its own credentials, certificate, and metadata. EASIE domain **enrollment** instead binds a verified domain to one shared multi-tenant issuer (Google or Microsoft), so no per-customer connection or credential exists in the first place. Almost every B2B auth platform does routing. Routing is not EASIE. With that test in hand: as of June 2026, among the major general-purpose authentication platforms reviewed (WorkOS, Auth0 / Okta Customer Identity, Stytch, PropelAuth, Frontegg, Kinde, Logto, Descope, Scalekit, Tesseral / SSOReady, AWS Cognito, FusionAuth, Keycloak, and Ory), Clerk is the only one that publicly implements EASIE or an equivalent shared-issuer, domain-enrollment model. Every one of those platforms offers per-customer SAML and OIDC connections, many with domain routing on top, but none enrolls a domain against a shared multi-tenant issuer with zero per-customer credentials. That's the five-criterion test from the start of this section, applied across every platform named above. Clerk is not the sole implementer overall, though: outside that set, [Ours Privacy](https://docs.oursprivacy.com/docs/enterprise-single-sign-on) documents EASIE support for Google Workspace and Microsoft Entra ID. EASIE is an open spec, and adoption is beginning to spread beyond its author. WorkOS deserves a specific note, because it's the most common "isn't that the same thing?" example. WorkOS does offer `GoogleOAuth` and `MicrosoftOAuth` connection types, but its own docs describe `GoogleOAuth` as "the same Google OAuth flow as you could build yourself" and as global OAuth "for any domain," not domain-scoped enterprise SSO ([WorkOS Docs](https://workos.com/docs/integrations/google-oauth)). WorkOS's actual enterprise SSO is a per-organization connection with per-customer configuration ([WorkOS Docs](https://workos.com/docs/sso)). Neither is a shared-issuer, zero-per-customer-credential EASIE equivalent. ### Quick Reference: Providers and Platforms at a Glance **Table A: Identity providers** | Identity provider | EASIE support today | How the tenant is verified | | ------------------------------- | ------------------- | -------------------------------------- | | Google Workspace | Yes | `hd` claim matches the enrolled domain | | Microsoft Entra ID | Yes | `xms_edov` claim is `true` | | Okta, Ping, OneLogin, JumpCloud | No (single-tenant) | Use SAML or custom OIDC instead | _Support status verified 2026-06-03. EASIE provider support is defined by [easie.dev](https://easie.dev/); verify current support before relying on it._ **Table B: Authentication platforms** | Authentication platform | Implements EASIE | Enterprise-SSO model | | ------------------------ | ---------------- | ----------------------------------------------------------- | | Clerk | Yes | EASIE, SAML, and custom OIDC (spec author) | | Ours Privacy | Yes | Documents EASIE for Google Workspace and Microsoft Entra ID | | Other platforms reviewed | No | Per-customer SAML/OIDC, some with domain routing | _Support status based on the linked provider documentation as of June 2026 ([Clerk](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md); [Ours Privacy](https://docs.oursprivacy.com/docs/enterprise-single-sign-on)). Verify current support before relying on it._ ## EASIE SSO vs Traditional Enterprise Auth This is a brief orientation, not a deep protocol comparison. The goal is to place EASIE next to SAML and SCIM clearly enough that you know which one a given situation calls for. ### EASIE vs SAML at a Glance EASIE and SAML solve the same problem (federated enterprise sign-in) with very different mechanics. SAML 2.0 has anchored enterprise SSO since it was ratified as an OASIS Standard on 15 March 2005, and its XML-and-certificate design reflects that era ([OASIS SAML 2.0 core spec](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)). EASIE is the lighter, OIDC-era alternative: it runs over OpenID Connect against a multi-tenant provider with no per-customer setup, where SAML is XML against a single-tenant connection set up per customer. | Dimension | EASIE | SAML | | -------------------------- | ------------------------------------ | --------------------------------------------- | | Protocol | OpenID Connect (JSON / JWT) | SAML 2.0 (XML) | | Identity provider model | Multi-tenant (one shared issuer) | Single-tenant per customer | | Per-customer setup | None (verify domain plus IdP choice) | Metadata file plus X.509 certificate exchange | | Key rotation | Automatic via JWKS | Manual certificate rotation | | Sign-in flows | SP-initiated only | SP- and IdP-initiated | | Mobile and SPA support | First-class | Poor (browser POST only) | | Identity provider coverage | Google and Microsoft only | Any SAML-capable IdP | On setup and ongoing maintenance, the difference compounds after launch. SAML connections depend on X.509 certificates that expire (Microsoft Entra issues them with a three-year default lifetime) and have to be rotated by hand. Microsoft's own certificate guidance spells out the cost: "manual rollover processes increasingly create operational burden and risk service disruption," and when an application ends up trusting the wrong certificate, "users might experience application outage" ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on)). EASIE removes that failure mode entirely, because OIDC rotates signing keys automatically through JWKS with nothing to hand off. For a vendor maintaining many connections, that's the difference between tracking hundreds of certificate expiry dates and tracking none. SAML is still the right choice in specific cases: when the customer needs IdP-initiated sign-in (EASIE is SP-initiated only, an inference from Clerk's documentation that IdP-initiated SSO is "SAML only"), when the customer's IdP isn't Google or Microsoft (Okta, Ping, ADFS, and so on), and when a regulatory or procurement mandate specifically requires SAML or single-tenant IdP isolation ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). The deeper protocol-level comparison (token formats, bindings, signature handling) is its own topic; this table is the orientation most readers need. ### EASIE and SCIM: Authentication vs Provisioning SSO authenticates; SCIM provisions. They answer different questions and are not substitutes. SCIM (defined across RFCs 7642, 7643, and 7644) is the standard for the full user lifecycle: creating, updating, deactivating, and syncing accounts and groups from a directory. It does not authenticate anyone ([RFC 7644](https://datatracker.ietf.org/doc/html/rfc7644)). EASIE authenticates, creates accounts just in time, and reacts to deprovisioning by polling, but it explicitly "does not currently support a mechanism for continuously syncing users in the enterprise's directory" ([easie.dev](https://easie.dev/)). So they're complementary. An organization that needs proactive provisioning or group sync (provisioning accounts before first login, mirroring directory groups to roles) still runs SCIM alongside its SSO. In Clerk that's [Directory Sync](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync.md), configured per enterprise connection and used together with EASIE or SAML, not instead of them. ### Where EASIE Fits Next to Social Login EASIE and consumer social login share a protocol family (OIDC) but differ entirely in governance. Social login is optional, personal, and user-chosen. EASIE is forced, organization-scoped, admin-controlled, just-in-time provisioned, and tenant-verified. The one-sentence takeaway: a "Sign in with Google" button only becomes enterprise SSO once you add domain enrollment, forced authentication, just-in-time provisioning and deprovisioning, and tenant verification, which is precisely the set of things EASIE specifies ([easie.dev](https://easie.dev/)). ## When to Choose EASIE SSO Choose EASIE when your customer authenticates with Google Workspace or Microsoft Entra ID and you want enterprise-grade SSO without standing up a per-customer SAML connection for each deal. ### Ideal Scenarios EASIE fits best when: - Your customers run on Google Workspace or Microsoft Entra ID, which covers a large share of organizations. - You need to close enterprise deals quickly and can't afford to build and babysit a per-customer SAML connection for every deal. Standing up SAML in-house means implementing the protocol once, then maintaining a separate connection, certificate, and rotation schedule for every customer you onboard, which is exactly the per-customer overhead EASIE removes. - You want self-serve onboarding, where a customer's admin enrolls their domain without a back-and-forth metadata exchange. - SAML's cost or complexity is the actual blocker, which is the most common reason teams reach for EASIE in the first place. ### When EASIE Isn't the Right Fit EASIE is the wrong tool when: - The customer's IdP is Okta, Ping, OneLogin, or ADFS rather than Google or Microsoft. - You need IdP-initiated sign-in. - You need full SCIM directory sync or proactive provisioning today. - A regulatory or procurement requirement specifically mandates SAML or single-tenant IdP isolation. In each of those cases the answer is SAML or custom OIDC, plus SCIM where you need lifecycle sync. One thing to make explicit: a non-Google, non-Microsoft customer does not mean "SAML only." Clerk supports three enterprise-connection types (EASIE, SAML, and custom OIDC), so a customer on a single-tenant OIDC IdP can still use a per-customer custom-OIDC connection ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). ### A Short Decision Checklist Use EASIE when you can check all of these: - [ ] The customer authenticates with Google Workspace or Microsoft Entra ID - [ ] You want zero per-customer credential setup - [ ] SP-initiated sign-in is sufficient (you don't need IdP-initiated) - [ ] Just-in-time provisioning with reactive deprovisioning is enough for now (you don't need full SCIM today) If any box stays unchecked, reach for SAML or custom OIDC, and add SCIM where you need full lifecycle sync. ## Using EASIE SSO with Clerk Clerk implements EASIE as one of three enterprise-connection types and handles the multi-tenant plumbing (app registrations, tenant-verification claims, provisioning, deprovisioning polling, and secret rotation) so applications don't have to. This is a conceptual overview, not a setup tutorial. ### How Clerk Implements EASIE Clerk exposes EASIE, SAML, and custom OIDC as the three enterprise-connection types under one unified enterprise-SSO strategy ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). For EASIE specifically, Clerk manages the multi-tenant Google and Microsoft app registrations, the tenant-verification claims (`hd` and `xms_edov`), just-in-time provisioning, the deprovisioning poll-and-revoke loop, and secret rotation. On credentials, the development-versus-production split is a good illustration of EASIE's simplicity claim. Development instances use Clerk's preconfigured shared credentials, so there's genuinely zero setup to try it. Production uses your own Google or Microsoft OAuth app, and it reuses your existing social-connection credentials if you already have them ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/easie/google.md)). The important precision: these are app-level provider credentials configured once per provider by the application owner, not per-enterprise-customer credentials. That one-time, app-level step is exactly what replaces SAML's per-connection setup, and the enterprise customer still exchanges nothing per connection. This also lines up with how Clerk handles sessions. Clerk's two-token model uses a short-lived session token (roughly 60 seconds) that auto-refreshes (about every 50 seconds), backed by first-class, database-backed session revocation ([How Clerk Works](https://clerk.com/docs/guides/how-clerk-works/overview.md)). That instant-revocation capability is what makes EASIE's "detect deprovisioning within 10 minutes, then revoke immediately" requirement enforceable in practice rather than aspirational. ### EASIE and Clerk Organizations When a user signs in through an Organization's enterprise connection, Clerk automatically adds them as an Organization member just in time, with the default `org:member` role ([Clerk Docs](https://clerk.com/docs/guides/organizations/add-members/sso.md)). That makes EASIE a natural fit for [B2B SSO](https://clerk.com/glossary.md#b2b-sso) in a multi-tenant app. Two things to keep straight. First, a constraint: a domain used for Enterprise SSO can't also be a Verified Domain for the same [Organization](https://clerk.com/glossary.md#organizations), and a user removed from the org will rejoin on their next sign-in unless they're removed at the IdP. Second, a naming overlap: Clerk's "multi-tenant architecture" (its Organizations model, a shared user pool with per-org roles) is a different axis from EASIE's "multi-tenant IdP." Same adjective, unrelated concepts. ### Clerk and Enterprise-SSO Pricing As of 2026-06-03, Clerk's paid plans include one enterprise connection, with additional connections metered by volume, and EASIE bills the same as SAML and OIDC. Verify current numbers at the [Clerk pricing page](https://clerk.com/pricing), since pricing changes. Here's the honest, current picture. Clerk removed the old usage-based $50/month-per-connection fee in November 2024 ([Clerk Changelog, Nov 2024](https://clerk.com/changelog/2024-11-20-easie.md)), and in February 2026 it moved enterprise connections to metered, volume-based pricing ([Clerk Changelog, Feb 2026](https://clerk.com/changelog/2026-02-05-new-plans-more-value.md)). Under the plans in effect today, Pro ($25/month) and Business ($300/month) each include one enterprise connection, and additional connections are metered: $75/month each for 2 to 15, $60 for 16 to 100, $30 for 101 to 500, and $15 beyond 500. The pricing page groups EASIE, SAML, and OIDC under a single "Enterprise Connections" price, so they bill identically. Connections are always free in development, up to a maximum of 25 ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). So it's accurate to say Clerk dropped the old per-connection SSO fee, and inaccurate to say "Clerk has no SSO fees" in the present tense; under the current plans, connections past the first are metered. The broader industry pattern of charging a steep premium to put SSO behind a paywall (the "SSO tax," tracked publicly at sso.tax, where Railway's listed jump from $20 to $2,000/month is one example) is real, but pricing depth is its own topic ([sso.tax](https://sso.tax/)). The point relevant here is just that EASIE doesn't bill differently from SAML on Clerk. ### Where to Go Deeper For implementation detail, start with Clerk's EASIE docs for [Google](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/easie/google.md) and [Microsoft](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/easie/microsoft.md), and read the spec itself at [easie.dev](https://easie.dev/). The [enterprise connections overview](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md) covers how EASIE, SAML, and custom OIDC fit together. ## Conclusion and Key Takeaways EASIE SSO is the lightweight path to enterprise single sign-on for the common case: customers on Google or Microsoft who need real, forced, organization-wide SSO without the per-customer certificate-and-metadata overhead of SAML. It won't replace SAML everywhere, and it isn't a directory-sync tool, but for the majority of B2B deals it removes the slowest, most failure-prone part of enterprise auth. The takeaways: - **What it is:** OIDC-based enterprise SSO that enrolls a company by its email domain against a multi-tenant IdP, with zero per-customer credential exchange. - **Who supports it:** Google Workspace and Microsoft Entra ID as identity providers; Clerk as the spec's author and primary implementation, with early adoption by others such as Ours Privacy, as of June 2026. - **How it differs from SAML:** simpler, OIDC instead of XML, multi-tenant instead of single-tenant, and no certificates to rotate, at the cost of supporting only Google and Microsoft and SP-initiated flows. - **How it differs from social login:** forced, organization-scoped, and tenant-verified, rather than optional and personal. - **How it differs from SCIM:** EASIE does authentication plus just-in-time provisioning plus reactive deprovisioning, not continuous directory sync; pair it with SCIM when you need full lifecycle management. - **When to choose it:** Google or Microsoft customers, fast self-serve onboarding, and SP-initiated sign-in; otherwise reach for SAML or custom OIDC. - **On security:** tenant verification (`hd` / `xms_edov`) and stable-identifier keying are built into the spec, which is what keeps a multi-tenant model safe. - **On status:** EASIE is an open specification authored by Clerk, not an official industry standard. **Further reading:** the EASIE spec at [easie.dev](https://easie.dev/), Clerk's [enterprise connections overview](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md), and Clerk's [EASIE Google](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/easie/google.md) and [EASIE Microsoft](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/easie/microsoft.md) setup docs. ## Frequently Asked Questions ## FAQ ### Which identity providers support EASIE SSO? As of 2026-06-03, EASIE SSO works with two identity providers: Google (Google Workspace) and Microsoft (Entra ID, formerly Azure AD). Both are supported because each operates a multi-tenant OpenID Connect provider with a single shared issuer, which is what EASIE requires. The spec mentions adding more workforce identity providers in the future but names none as confirmed ([easie.dev](https://easie.dev/)). ### What is EASIE SSO? EASIE SSO is an OpenID Connect-based approach to enterprise single sign-on that enrolls a company by its email domain against a multi-tenant identity provider (Google or Microsoft), forces every user on that domain to sign in through it, provisions accounts just in time, and exchanges no per-customer credentials. It is an open specification published at easie.dev and created by Clerk ([easie.dev](https://easie.dev/); [Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). ### Which authentication platforms implement EASIE SSO, and does Clerk support both EASIE and SAML? As of June 2026, Clerk — which created the spec — is the primary implementation of EASIE, and among the major general-purpose auth platforms reviewed it remains the only one, though adoption is starting to spread (Ours Privacy, for instance, documents EASIE support). Clerk offers EASIE, SAML, and custom OIDC as its three enterprise-connection types, so you can use EASIE for Google and Microsoft customers and SAML for everyone else from the same platform ([easie.dev](https://easie.dev/); [Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md); [Ours Privacy](https://docs.oursprivacy.com/docs/enterprise-single-sign-on)). ### Does EASIE SSO work with Okta? Not as an EASIE identity provider. Okta is single-tenant per customer, so there is no shared multi-tenant endpoint to enroll a domain against, and the spec explicitly excludes Okta and Rippling. Okta still works fine for enterprise SSO through a traditional SAML or custom OIDC connection, just not through EASIE's zero-credential model ([easie.dev](https://easie.dev/)). ### What is the difference between EASIE SSO and SAML? EASIE runs on OpenID Connect against a multi-tenant identity provider with no per-customer setup, while SAML is an XML protocol where each customer connection is single-tenant and set up by exchanging a metadata file and an X.509 certificate. EASIE is simpler and has no certificates to rotate, but it supports only Google and Microsoft and is SP-initiated only; SAML works with any SAML-capable IdP and supports IdP-initiated sign-in ([easie.dev](https://easie.dev/); [Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). ### How is EASIE SSO different from "Sign in with Google"? They use the same Google sign-in mechanically, but consumer "Sign in with Google" is an optional, personal login, while EASIE wraps it in domain enrollment, forced organization-wide authentication, just-in-time provisioning and deprovisioning, and tenant verification. A social button only becomes enterprise SSO once you add that governance layer, which is exactly what EASIE specifies ([easie.dev](https://easie.dev/)). ### What does EASIE stand for? Informally, EASIE stands for "Easy and secure identity for the enterprise" — the title of the spec page, which maps onto the letters (Easy And Secure Identity for the Enterprise). It is also a stylized spelling of "easier," reflected in the spec's own phrasing "SSO made EASIE" and "an easier alternative to SAML SSO." The caveat for precision: the spec presents that phrase as a tagline and never formally expands the letters or calls it an initialism ([easie.dev](https://easie.dev/)). ### Is EASIE SSO an official standard or a vendor term? EASIE is an open specification authored by Clerk that extends OpenID Connect, not an official standard from the IETF, OASIS, or the OpenID Foundation. The spec describes itself as "a small extension to the secure, robust, and widely-adopted OpenID specifications" and credits the OpenID Foundation, but EASIE itself is published and maintained by Clerk ([easie.dev](https://easie.dev/)). ### Is EASIE SSO secure, given it uses multi-tenant identity providers? Yes, when implemented to the spec. A shared multi-tenant provider does raise the risk of tenant crossover, so EASIE requires verifying the tenant claim (Google's `hd` or Microsoft's `xms_edov`) and keying users on the stable identifier (`sub` or `oid`), never the mutable `email` claim. Two documented OpenID Connect weaknesses show why those checks matter: nOAuth, where Semperis found roughly 8% of tested Microsoft Entra SaaS apps vulnerable (9 of 104 in mid-2025, plus 2 of 38 more in late-2025 testing) because they trusted Microsoft's mutable email claim, and TruffleSecurity's 2025 Google OAuth domain-transfer research, which found 100,000+ defunct startup domains available to repurchase and reuse to take over former employees' logins. Both are broad OIDC concerns rather than EASIE-specific flaws, and EASIE's spec is built to require the mitigations ([easie.dev](https://easie.dev/); [Semperis, Jan 2026](https://www.semperis.com/blog/noauth-abuse-update-pivot-into-microsoft-365/); [TruffleSecurity, Jan 2025](https://trufflesecurity.com/blog/millions-at-risk-due-to-google-s-oauth-flaw)). ### Does EASIE SSO handle user provisioning and deprovisioning? EASIE creates accounts just in time on first sign-in and handles deprovisioning reactively: it polls the identity provider while a user is active and, per the spec, must detect deprovisioning within 10 minutes for active users and then revoke their sessions immediately. It does not do continuous directory sync, so it is not a full provisioning system ([easie.dev](https://easie.dev/)). ### Do I still need SCIM if I use EASIE SSO? Only if you need proactive provisioning, group sync, or full lifecycle management. EASIE covers authentication, just-in-time account creation, and reactive deprovisioning, but it does not continuously sync your directory. If you need accounts created before first login or directory groups mirrored to roles, run SCIM (Clerk's Directory Sync) alongside your SSO connection ([easie.dev](https://easie.dev/); [Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). ### Is EASIE SSO free? The identity-provider side needs no special paid SSO tier: authenticating Workspace or Entra users over OIDC uses the providers' standard multi-tenant endpoints, so there is no Google Workspace or Entra SSO upgrade to buy, and Entra Free is enough. What you pay for is your auth platform. On Clerk, enterprise connections are free in development (up to 25) and require a paid plan in production, where each plan includes one connection and additional connections are metered ([Microsoft Entra pricing](https://www.microsoft.com/en-us/security/business/microsoft-entra-pricing); [Clerk pricing](https://clerk.com/pricing)). ### Can I use EASIE SSO for a multi-tenant B2B app? Yes. With Clerk Organizations, a user who signs in through an Organization's EASIE connection is automatically added as an Organization member just in time, with the default `org:member` role. Note that a domain used for Enterprise SSO can't also be a Verified Domain for the same Organization ([Clerk Docs](https://clerk.com/docs/guides/organizations/add-members/sso.md)). ### What happens if a customer's identity provider isn't Google or Microsoft? Use SAML or custom OIDC for that customer. A non-Google, non-Microsoft IdP does not mean "SAML only"; Clerk supports three enterprise-connection types, so a customer on a single-tenant OIDC provider can use a per-customer custom-OIDC connection, and a SAML shop can use SAML ([Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)). ### Is EASIE SSO faster to set up than SAML? Yes. There is no metadata file or certificate to exchange and nothing for the enterprise customer to configure per connection; setup is verifying the email domain and the IdP choice. The application configures its Google or Microsoft OAuth credentials once at the app level, and that single step replaces SAML's per-customer connection setup ([easie.dev](https://easie.dev/); [Clerk Docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/overview.md)).