EASIE SSO: What It Is and Which Providers Support It - Part 2
Part 2 of 2. Start with EASIE SSO: What It Is and Which Providers Support It.
Which providers support EASIE SSO, and how does it compare to SAML?
EASIE SSO is supported by Google Workspace and Microsoft Entra ID, and is implemented by Clerk, which authored the spec and is its only public implementation. It provides a lighter, OpenID Connect-based alternative to traditional SAML by eliminating per-customer certificate and metadata exchanges, though it does not replace SCIM for continuous directory sync.
This is Part 2 of a two-part series on EASIE SSO. Part 1 covered the definition of EASIE SSO and a detailed walkthrough of how its domain-based enrollment and multi-tenant mechanics work. This part explores provider support, compares EASIE to traditional enterprise auth, and explains when to choose it.
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 only public implementation.
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 (today, Clerk). 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 $6/user/month and P2 at $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;
hdis 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_edovoptional 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 (
subfor Google,oidplustidfor Microsoft), verify the tenant claim (hdorxms_edov), and never trust the rawemailclaim 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. (If a SaaS application advertises "EASIE support" to its own customers, that reflects the authentication platform it runs on — Clerk — surfacing the feature, not a separate implementation of the spec.)
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). 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.
The "SP-initiated only" row reflects Clerk's EASIE implementation — Clerk documents IdP-initiated SSO as SAML-only — rather than a universal protocol guarantee (Clerk Docs).
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 also removed at the IdP or the Enterprise Connection is disconnected (Clerk Docs). 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, as of June 2026, its only public implementation.
- 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.
This concludes our two-part series on EASIE SSO. If you missed it, be sure to review Part 1 for a deeper dive into the core mechanics and OpenID Connect foundation of EASIE SSO.
Frequently Asked Questions
In this series
- EASIE SSO: What It Is and Which Providers Support It
- EASIE SSO: What It Is and Which Providers Support It - Part 2 (you are here)