Keycloak, Auth0, Entra, Ping or ClavionX? Choosing by Architecture, Not Feature List

Put the feature matrices of a handful of identity platforms side by side and they're almost identical. OIDC: yes. SAML: yes. MFA, passkeys, SCIM, social login, B2B organizations, audit logs: yes, yes, yes. Occasionally a cell says "roadmap". A procurement team can spend a month on that spreadsheet and learn nearly nothing, because identity platforms eventually look the same. The protocols force convergence on what they do.

They don't converge on how. Underneath identical checkboxes, these platforms made very different decisions about a handful of things. Those decisions determine what your incidents look like, what your upgrades cost, and what you'll be unable to do in year three.

This post is the summary of a series that looked at each platform against ClavionX in depth:

• Keycloak vs ClavionX: When the Extension Model Is the Product
• Auth0 vs ClavionX: The Cost of Code in the Login Path
• Microsoft Entra vs ClavionX: An Identity Platform That Is Really a Directory
• Ping Identity vs ClavionX: What Twenty Years of Federation Buys You
• Okta vs ClavionX: The Control Point Is Also the Target
• Amazon Cognito vs ClavionX: The Decisions You Make on Day One
• FusionAuth vs ClavionX: Code Without I/O, and Where the Line Moves
• Zitadel vs ClavionX: Event Sourcing vs Event-Carried State
• Ory vs ClavionX: Composable Components, and Who Owns the Seams
• Authentik vs ClavionX: Python in the Policy Engine, and One Database for Everything

Disclosure: I work on ClavionX. For a lot of readers the answer below won't be ClavionX, and the section on when it's the wrong choice is the one I'd most like you to read.

Four questions that actually separate them

1. Where does your custom logic run?

This question predicts more about long-term operations than any other.

Read that column top to bottom and it's a spectrum, from "anything is possible" to "almost nothing is possible, by design". No position on it is free. At one end, the cost appears as upgrades and incidents. At the other, it appears as feature requests you can't satisfy.

ClavionX has one honest exception. LDAP and Active Directory password verification is a synchronous bind at login, because a password you don't hold can't be pre-synced.

2. Who holds the pen on security posture?

• In Keycloak, the realm administrator does, per client, per realm.
• In Auth0, the tenant administrator does, and any Action author can add claims or deny access.
• In Entra, the publisher defines the app and each consuming tenant wraps it in its own Conditional Access policies.
• In Ping, whoever owns each connection and policy does, across however many engines you've licensed.
• In FusionAuth, tenant and application administrators do, along with whoever writes the lambdas.
• In Zitadel, the organization that owns a project decides which roles it grants to other organizations, and each receiving organization manages its own users within that set.
• In Ory, your own login and consent application does. Hydra issues tokens once your app accepts the request.
• In authentik, whoever can edit flows, policies and expressions does, and that power is effectively code-level.
• In Okta, the org's administrators do, through app-level sign-on and authentication policies.
• In Cognito, whoever owns the user pool's infrastructure code and its Lambda triggers does. Often that's the application team rather than a security team.
• In ClavionX, the canonical application definition does. Redirect URIs, grant types, PKCE and token policy are fixed there, and a tenant can't loosen them.

If you're federating a sovereign enterprise's workforce, you want the consuming side to hold the pen, which is Entra's model. If you're a product team serving many customer tenants, you probably want one posture you can prove, which is ClavionX's. Many "which vendor?" debates are really this question in disguise.

3. Who operates it?

"Self-managed" should be read as a cost, not just a capability. It means you own upgrades, cache topology, key rotation, on-call and the deploy that logs everyone out. It's the right choice when data residency, air-gapped environments or regulatory control require it. When the only reason is that the license is cheaper, it's usually the wrong one.

4. How mature is the thing you actually need?

This is where maturity has to be measured per capability, not per vendor.

A vendor comparison that doesn't include a table like this, with its own product's gaps in it, is a sales document.

A decision path

Most real decisions resolve with a few questions asked in the right order:

flowchart TD
    A{"Workforce identity in a<br/>Microsoft 365 organization?"} -- yes --> E["Entra"]
    A -- no --> O{"Workforce SSO across<br/>a broad SaaS estate?"}
    O -- yes --> OK["Okta"]
    O -- no --> W{"All-in on AWS, users need<br/>AWS credentials directly?"}
    W -- yes --> CG["Cognito"]
    W -- no --> B{"Hundreds of legacy SAML partners,<br/>or login as a compliance workflow?"}
    B -- yes --> P["Ping"]
    B -- no --> C{"Need custom code at login<br/>(real-time external signals)?"}
    C -- "yes, hosted" --> AU["Auth0"]
    C -- "yes, self-run" --> K["Keycloak, FusionAuth,<br/>Zitadel, Ory or authentik"]
    C -- no --> D{"Multi-tenant product needing<br/>per-customer keys and uniform posture?"}
    D -- yes --> X["ClavionX is worth evaluating"]
    D -- no --> F["Any of them; choose on<br/>ops model and cost"]

Two notes on reading it. First, the paths aren't exclusive. A very common architecture is Entra or Okta for the workforce, with a product-facing platform federating to each customer's IdP over SAML and receiving users through SCIM. Second, the last box is more common than vendors like to admit. For a straightforward application with modest requirements, any of them will work. At that point the ops model and the price of the next five years matter more than architecture.

When ClavionX is the wrong choice

Directly, and without softening:

• You need token exchange, delegation chains or agent authorization this quarter. Those are planned or in design, not shipped.
• You need logic at login that depends on real-time external signals. ClavionX won't run it, by design, and pre-sync can't fully replace it.
• You need adaptive, risk- or device-based access policy today. It's planned, not built.
• You need self-service password recovery with a complete admin UI. The service layer exists and the control-plane UI is still in progress.
• You need SCIM beyond /Users, such as group provisioning or bulk operations.
• Your organization's risk model requires a vendor with a long production track record, or a long list of analyst reports and reference customers. ClavionX is younger than every other platform in this series, and a clean design isn't a substitute for years of production incidents already survived.

When it's worth a serious look

Consider ClavionX when you're building a multi-tenant product and each customer should get its own issuer and signing keys. It also fits when you want an application's security posture to be provable rather than audited tenant by tenant, and when a login path that depends on nothing you don't control matters more than one that can call anything. Finally, it fits when you need to run the runtime yourself and want a strict separation between the control plane and the runtime that serves logins, so an admin outage or admin load never touches sign-in.

If that describes your situation, run the experiments in How to Evaluate an Identity Vendor Without Reading Marketing Pages against ClavionX and against whichever of the others you're considering. Include the exit test. Then read Migrating Off an Identity Provider Without Downtime before you sign anything, with any vendor, including this one.

The actual difference

Every platform in this series is a coherent answer to a slightly different question:

• Keycloak: what if the identity server could be made to do anything?
• Auth0: what if identity were a developer tool you never had to operate?
• Entra: what if identity were an attribute of the directory that already runs the organization?
• Ping: what if every federation problem anyone has ever had came pre-solved?
• Okta: what if the identity control point were neutral, comprehensive and run by specialists?
• Cognito: what if identity were just another primitive in your cloud account?
• FusionAuth: what if you could run code in the token path, as long as it can't wait on anything?
• Zitadel: what if the identity system were the sum of every event that ever happened to it?
• Ory: what if the identity system were a set of components joined at protocol boundaries you own?
• authentik: what if an organization's admins had a programming language and needed only one database?
• ClavionX: what if the identity runtime did less, but could guarantee all of it?

The features converge and the questions don't. Pick the platform whose question matches yours, and be suspicious of any comparison, this one included, that claims one question is simply correct.

Vendor details were checked against public documentation and announcements in September 2026, and all of these products change quickly. Verify anything load-bearing before you rely on it. ClavionX capability status is taken from its public docs and feature matrix. I work on ClavionX.