Skip to main content
Articles

EASIE SSO: What It Is and Which Providers Support It

Author: Roy Anger
Published: (last updated )

What is EASIE SSO, and which providers support it?

Enterprise customers increasingly demand SSO, but the usual way to deliver it — SAML — is heavy. Each customer connection is its own single-tenant integration, stood up by exchanging a metadata file and an X.509 signing certificate and then kept working by rotating that certificate before it expires. For the common case where the customer already signs in with Google Workspace or Microsoft Entra ID, there is a lighter option.

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). As of June 2026, Clerk is the only authentication platform that publicly implements EASIE SSO as the specification defines it.

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.

This is Part 1 of a two-part series on EASIE SSO. This part defines EASIE SSO and provides a detailed walkthrough of how its mechanics work. Part 2 covers which identity providers support it, how it compares to SAML and SCIM, and when to choose it.

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 as of June 2026 remains the only authentication platform to publicly implement the spec. Part 2 of this series covers which providers support EASIE in more detail.

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. Because that flow always begins at the application — the user clicks "Sign in with Google" or "Sign in with Microsoft" there, rather than launching the app from an IdP dashboard — EASIE connections are SP-initiated only. Clerk documents IdP-initiated SSO as available for SAML connections only, so its EASIE and custom-OIDC enterprise connections don't expose an IdP-initiated flow (Clerk Docs). 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.

Conclusion

EASIE SSO simplifies enterprise authentication by leveraging multi-tenant identity providers and OpenID Connect to remove the per-customer setup burden. By enrolling an email domain, forcing authentication, and provisioning just-in-time, it offers a streamlined alternative to traditional SSO setups. In Part 2 of this series, we will cover which specific identity providers and platforms support EASIE today, how it compares directly to SAML and SCIM, and when it is the right choice for your application.

Frequently Asked Questions

In this series

  1. EASIE SSO: What It Is and Which Providers Support It (you are here)
  2. EASIE SSO: What It Is and Which Providers Support It - Part 2