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 over 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⁠, and implements it alongside SAML and OIDC (Clerk Docs); other vendors have since adopted it, including Ours Privacy⁠. 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.

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⁠). 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). 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⁠ 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⁠ 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 — Easy And Secure Identity (for the) Enterprise. 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⁠). 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. OIDC issues signed ID tokens (which are JSON Web Tokens), exposes discovery and UserInfo endpoints, and rotates signing keys automatically through a published JWKS endpoint (OpenID Connect Core 1.0⁠).

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⁠).

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 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 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. 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⁠). The 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⁠). 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⁠). 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⁠). 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⁠).

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

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

{
  "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⁠; Microsoft Learn⁠). 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⁠).

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⁠). 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.

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

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⁠). 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⁠).

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⁠). 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⁠). 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⁠).

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⁠; Microsoft Learn⁠).

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⁠).

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). 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⁠ 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⁠). WorkOS's actual enterprise SSO is a per-organization connection with per-customer configuration (WorkOS Docs⁠). Neither is a shared-issuer, zero-per-customer-credential EASIE equivalent.

Quick Reference: Providers and Platforms at a Glance

Table A: Identity providers

Support status verified 2026-06-03. EASIE provider support is defined by easie.dev⁠; verify current support before relying on it.

Table B: Authentication platforms

Support status based on the linked provider documentation as of June 2026 (Clerk; Ours Privacy⁠). 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⁠). 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.

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⁠). 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). 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⁠). 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⁠).

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, 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⁠).

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

A Short Decision Checklist

Use EASIE when you can check all of these:

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). 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). 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). 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). That makes EASIE a natural fit for 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, 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, 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), and in February 2026 it moved enterprise connections to metered, volume-based pricing (Clerk Changelog, Feb 2026). 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).

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⁠). 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 and Microsoft, and read the spec itself at easie.dev⁠. The enterprise connections overview 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⁠, Clerk's enterprise connections overview, and Clerk's EASIE Google and EASIE Microsoft setup docs.

Frequently Asked Questions