Ory vs ClavionX: Composable Components, and Who Owns the Seams

The first time a team deploys Ory Hydra, there's a moment of confusion that tells you everything about its design. The OAuth 2.0 server is running. Discovery works and the JWKS endpoint serves keys. A client redirects to /oauth2/auth, and Hydra immediately redirects the browser somewhere else, to a URL the team was supposed to configure: your login app.

Hydra has no login page. It has no user database and no password check. It knows how to run the protocol and issue tokens, and it expects you to tell it who the user is. Your application receives a login_challenge, authenticates the user however it likes, calls Hydra's admin API to accept the challenge, and hands the browser back. The same happens for consent.

Most identity platforms offer extension points in the login path. Hydra is an extension point, surrounding a protocol engine. That makes Ory the far end of every spectrum this series has drawn, and the most useful place to ask a question the other comparisons skirted. When customer logic has to exist, where should the seam between it and the identity system sit?

Disclosure: I work on ClavionX. Ory is a serious, well-engineered open-source stack, and for several kinds of team it's the better choice. The post says which.

What Ory actually is

Ory is a set of open-source components, Apache 2.0 licensed and written in Go. Each one does one job:

• Hydra: an OAuth 2.0 and OpenID Connect server, OpenID Certified, that delegates login and consent to your application through the flow described above.
• Kratos: headless identity and user management. It handles registration, login, MFA, passkeys, recovery, verification and profile settings as API-driven flows, and you build the UI.
• Keto: a permission system modeled on Google's Zanzibar paper, answering "may this subject do this to this object?"
• Oathkeeper: an identity-aware proxy that authenticates and authorizes requests before they reach your services.
• Polis: enterprise SSO through SAML and OIDC connections with SCIM directory sync. It came from Ory's 2025 acquisition of BoxyHQ, whose Jackson project it evolved from.

You can run the components yourself, run them on Ory Network (Ory's managed service), or buy the Ory Enterprise License for self-hosted deployments with extra features, multi-tenancy and CVE patch SLAs. Hydra in particular runs at very large scale, and its README cites OpenAI among its users.

The seam is a protocol, not a plugin

What sets Ory apart from every other platform in this series isn't that it lets you run code in the login. It's where the boundary sits.

Keycloak puts your code inside the server, behind a Java interface. Auth0 and FusionAuth run it in a sandbox inside the vendor's process or infrastructure. Entra, Okta, Cognito and Zitadel call out from the middle of their own flow and wait. Hydra does something structurally different. It hands the whole browser to your application through a redirect, and waits for your application to call back through a documented, versioned HTTP API:

sequenceDiagram
    participant B as Browser
    participant H as Hydra
    participant L as Your login app
    B->>H: /oauth2/auth (client request)
    H-->>B: 302 → login app ?login_challenge=…
    B->>L: Login page
    L->>L: Authenticate (your logic, e.g. via Kratos)
    L->>H: PUT /admin/…/login/accept (subject, remember)
    H-->>L: redirect_to
    L-->>B: 302 → Hydra
    B->>H: Continue → consent (same pattern) → tokens

That boundary has properties an in-process extension point can't have:

• The contract is the protocol, not an internal interface. The login and consent API is documented and versioned as public API from day one, rather than being an internal interface customers built on anyway. Every Extension Point Is a Permanent Public API argued that every extension point becomes one eventually. Hydra accepted that at the start and designed the seam to be one.
• Failures are contained to the flow that owns them. If your login app is slow, logins through Hydra are slow. Token refreshes, introspection, JWKS and discovery are unaffected, because Hydra never waits on your code outside the login and consent steps.
• Isolation is physical. Your code runs in your process, in your deployment, with your observability. Nothing you write shares memory with Hydra's signing keys.

This is the strongest form of "if logic must exist, put it at a clean boundary", and it's genuinely good design. A login that depends on your login app is also exactly what you'd want in some architectures. You already own authentication, perhaps a decade-old user store you can't move, and you need a standards-compliant OAuth 2.0 layer on top without migrating anything. Hydra is purpose-built for that case, and it's a case where ClavionX, which owns the user store, doesn't fit at all.

The cost: you own the seams

The price of composition is that the parts are yours to connect, and the connections are where security bugs live.

With Kratos and Hydra together, your login app bridges Kratos sessions to Hydra login challenges. With Kratos headless, you write the login page, and the login page is security-critical code. It has to handle CSRF correctly, avoid account enumeration through different error messages, rate-limit in the right place without locking users out as a DoS vector, and handle recovery flows without creating a takeover path. Kratos provides secure flow primitives and reference UIs, which helps a lot. The page, and how it uses those primitives, is still yours to get right.

Then there are the operational seams. Each component has its own versions, configuration, migrations and upgrade notes, and a production stack might run four of them. Each boundary between them adds latency, a failure mode and a compatibility matrix. Ory Network removes most of that burden for teams willing to use the managed service. Self-hosted, it's real platform work.

Kratos also has synchronous webhooks. Actions attached to flow events can be configured to parse the response and modify the identity before it's saved, or to interrupt the flow and block it. That's the same "is this webhook on the commit path?" question raised in the FusionAuth comparison. The answer is per-hook configuration, and it should be audited as such.

Authorization as a separate service

Ory's architecture makes one argument this blog has made at length. Keto, the permission system, is a different service from Kratos and Hydra. Identity answers who you are. A separate relationship-based engine answers what you may do. Identity Isn't Your Authorization Engine makes the case for that split, and it's notable that Ory drew the boundary in its product structure rather than leaving it as advice.

ClavionX draws the same boundary in a narrower way. It carries coarse authorization metadata, such as groups, permissions per resource server and claims, and it supports token introspection. It doesn't offer a Zanzibar-style engine and doesn't intend to. If you need fine-grained relationship authorization, Keto or another dedicated engine is the answer next to either platform.

Composed vs integrated

The central trade-off is familiar from outside identity. It's the difference between assembling a stack from components and adopting an integrated system.

Ory gives you components with sharp boundaries, protocol-level seams and freedom to replace any part. The cost is assembly: login UI, glue, and multiple lifecycles. Its multi-tenancy is a managed-service and enterprise-license concern rather than a primitive of the open-source components.

ClavionX is integrated. It has hosted login pages with per-tenant branding, a user store, MFA, passkeys, SAML in both roles, SCIM and an admin control plane, all in one product with one lifecycle. Tenancy is built in: each tenant gets its own OIDC issuer and signing keys, and applications can be declared global with a security posture tenants can't loosen. Internally it's split along a different seam from Ory's. The admin control plane and the login-serving runtime are separate services, and the runtime reads projected configuration and never calls the control plane during a request. That's a seam for failure isolation, not for customer replaceability. You can't swap out ClavionX's login the way you can swap out Hydra's.

The costs run the other way too. ClavionX's login UI is customizable in branding, not in structure. It runs no customer logic in the login path, has no bring-your-own-user-store mode except LDAP password verification, and doesn't have Ory's track record at scale. Its RFC 8693 token exchange is planned, and its agent identity model is in design.

When Ory is the better choice

Pick Ory when:

• You already own authentication and need a certified OAuth 2.0/OIDC layer on top of it, without migrating users. That's Hydra's purpose.
• The login experience is part of your product, and you want complete control of every pixel and step, with headless Kratos flows behind it.
• You want open-source components you can compose, replace and read, under Apache 2.0.
• You need fine-grained, relationship-based authorization in the same ecosystem.
• You have the engineering capacity to own the login UI and the glue, or you'll use Ory Network to shed the operational part.

ClavionX fits better when you want an integrated platform rather than a kit, especially for a multi-tenant product needing per-tenant issuers and keys and uniform security posture. It also fits when you'd rather not own security-critical login UI code, and when the priority is a login path whose behavior is entirely the platform's responsibility.

The actual difference

Every platform in this series answers the question of where customer logic should go. Most say "at a hook", differing only in how the hook is sandboxed and timed. Ory's answer is at a protocol boundary, so completely that the identity service becomes the thing that surrounds your logic. ClavionX's answer is nowhere, so completely that some requirements can't be met.

The lasting lesson applies to any identity architecture. If a seam must exist, make it a documented protocol with a clear owner, not an internal interface people happen to build on. Ory built its products around that rule. Everyone else in this series either adopted it gradually or is still paying for not having done so.

Vendor details are from Ory's public documentation, repositories and announcements as of September 2026. ClavionX capability status is taken from its public docs and feature matrix. I work on ClavionX.