Ory
Last verified 2026-03-12 · Reviewed by guptadeepak
Editorial verdict
Ory is the most architecturally modern open-source CIAM in 2026, Go-based, Kubernetes-native, composable components, strict Apache 2.0, with native Zanzibar-style FGA via Keto that no other full-platform vendor in this index ships natively. The trade-off is operational scope: running four composable services rather than one binary suits Kubernetes-native teams and frustrates everyone else. For teams that want OSS plus FGA from one vendor, Ory is the singular pick.
Last verified by @guptadeepak on 2026-03-12.
At a glance
- Best for
- Teams that want OSS CIAM with native FGA without running a separate authz vendor
- Pricing
- tiered-mau
- Free tier
- 25,000 MAU
- Deployment
- self-hosted, cloud-saas, hybrid
- SOC 2 Type II
- Yes
- Passkeys
- Native
- Self-host
- Yes
- Open source
- No
Funding & business
- Funding model
- Venture-backed
- Total raised
- $27.5M
- Latest round
- Series A · $22.5M · 2021
- Years in business
- 9 yrs
- Round led by
- Insight Partners
- Profitable
- Not disclosed
Open-source identity (Kratos, Hydra, Keto); $22.5M Series A plus a $5M extension. In-Q-Tel (CIA-linked) on the cap table.
Funding data from primary source. See also the CIAM investor landscape.
Strengths
- Most modern open-source CIAM architecture in 2026, Go-based, Kubernetes-native, components composable (Kratos / Hydra / Keto / Oathkeeper).
- Keto ships native Zanzibar-style FGA, one of two genuinely OSS Zanzibar implementations alongside OpenFGA.
- Strict Apache 2.0 licensing across all components; no commercial-use clauses or contributor licensing surprises.
- EU-headquartered with EU data residency on Ory Network managed offering, meaningful for European buyers.
Limitations
- Component model means more moving parts, Kratos for users, Hydra for OAuth server, Keto for authz, Oathkeeper for proxy, operational scope is broader than Keycloak or FusionAuth.
- B2B Organizations model is less first-class than dedicated B2B vendors (WorkOS, Frontegg).
- Adaptive risk decisioning and bot defense are weak; pair with Authsignal or external risk engines.
- DX is improving but the component decomposition imposes a learning curve some teams find too high.
Capability matrix
Every vendor scored on the same axes. See the methodology for criteria.
| Password authentication | Yes |
|---|---|
| Social login | Yes |
| Magic links | Yes |
| SMS OTP | Partial |
| Email OTP | Yes |
| TOTP (authenticator app) | Yes |
| Push MFA | No |
| WebAuthn / passkeys | Yes |
| Biometric | Yes |
| Hardware security keys | Yes |
| SAML SSO | Partial |
| OIDC SSO | Yes |
| OAuth 2.0 SSO | Yes |
| Enterprise federation | Partial |
| Passwordless-only flows | Yes |
| Adaptive MFA | No |
| Step-up auth | Yes |
| RBAC | Yes |
|---|---|
| ABAC | Yes |
| ReBAC | Yes |
| FGA engine | Yes |
| API authorization | Yes |
| Fine-grained permissions | Yes |
| Self-service registration | Yes |
|---|---|
| Progressive profiling | Yes |
| Self-service account | Yes |
| Bulk user import | Yes |
| Admin user search | Yes |
| Custom user metadata | Yes |
| Organizations / tenants | Partial |
| Multi-tenancy | Yes |
| REST API | Yes |
|---|---|
| GraphQL API | No |
| SDKs | js, node, go, python, php, ruby, java, dotnet, rust |
| CLI | Yes |
| Terraform provider | Yes |
| Local emulator | Yes |
| Extension model | Webhooks + custom UI nodes (self-service flows are configurable, not hooks-driven) |
| Bot detection | No |
|---|---|
| Breached password detection | Yes |
| Brute-force protection | Yes |
| Anomaly detection | No |
| Log streams | Yes |
| Audit logs | Yes |
| GDPR data export | Yes |
| PII minimization | Yes |
| Post-quantum roadmap | No |
| MCP support | Partial |
|---|---|
| OAuth 2.1 | Yes |
| Dynamic client registration | Yes |
| Agent vs human token separation | Partial |
| Web Bot Auth | No |
| SOC 2 Type II | Yes |
|---|---|
| ISO 27001 | Yes |
| ISO 27018 | No |
| HIPAA | Partial |
| PCI DSS | No |
| GDPR | Yes |
| CCPA | Yes |
| FedRAMP | No |
| EU data residency | Yes |
| Consent management | Partial |
|---|---|
| Preference center | Partial |
| Purpose-specific consent | Partial |
| Integrates with CMPs | n/a |
Pricing
| 10,000 MAU | $29/mo |
|---|---|
| 100,000 MAU | $350/mo |
| 500,000 MAU | $1,400/mo |
| 1,000,000 MAU | $2,800/mo |
- Self-hosted Ory components are Apache 2.0, free to run; pay only operational cost
- Ory Network (managed) is per-MAU like a SaaS CIAM, with EU data residency by default
- Keto (FGA) self-hosted is free; managed Keto on Ory Network priced separately
Estimates use the standard assumptions in our methodology. Always confirm with the vendor.
Best for
- Teams that want OSS CIAM with native FGA without running a separate authz vendor
- EU-based or data-residency-sensitive deployments wanting managed CIAM with EU sovereignty
- Kubernetes-native architectures comfortable composing services
Not for
- Teams that want a single deployable artifact (look at FusionAuth or Keycloak)
- B2B SaaS prioritizing Admin Portal UX (look at Frontegg)
- Workloads requiring FedRAMP or PCI DSS direct attestation
FAQ
- What are Kratos, Hydra, Keto, and Oathkeeper?
- Kratos is the user identity and self-service flows server. Hydra is the OAuth 2.0 / OIDC authorization server. Keto is the Zanzibar-style fine-grained authorization service. Oathkeeper is the identity-aware reverse proxy that enforces auth at the network edge. They compose; you can run any subset.
- Is Ory Network the only paid product?
- Effectively yes, the components are Apache 2.0 and free to self-host. Ory Network is the managed offering that runs the components for you with EU data residency, support, and the Ory Console. Paid plans on Ory Network start at $29/month.
- How does Ory FGA (Keto) compare to OpenFGA?
- Both are Zanzibar implementations. Keto pre-dates OpenFGA and is more tightly integrated with the rest of the Ory stack; OpenFGA is a CNCF project with broader vendor neutrality. For teams already running Ory components, Keto is the natural choice; for teams running other CIAM, OpenFGA is the more common pick.
Sources
- Ory Pricingaccessed 2026-04-22
- Ory Documentationaccessed 2026-04-22
- Ory GitHubaccessed 2026-04-22
What Ory is
Ory was founded in 2017 in Munich with a thesis that the OSS CIAM market needed a Kubernetes-native, components-first alternative to Keycloak's monolithic Java service. The product line consists of four Apache 2.0 services that compose: Kratos (identity and self-service), Hydra (OAuth 2.0 / OIDC authorization server), Keto (Zanzibar-style fine-grained authorization), and Oathkeeper (identity-aware proxy). Ory Network is the managed offering, sold per-MAU with EU data residency by default. The buyer is typically a team that wants OSS CIAM with modern operational ergonomics, or a team running on EU infrastructure that needs sovereignty.
Where Ory wins
The architecture is the differentiator. Each component is a single Go binary with a small footprint, designed for Kubernetes deployment with the standard stateless-service patterns. Schema migrations are first-class. Components compose: a team can run only Kratos for user management, only Hydra for OAuth server, only Keto for FGA, or any combination, without paying for what isn't needed.
Keto's native Zanzibar-style FGA is unique in this index. Among full-platform CIAM vendors, only Auth0 (with Auth0 FGA) and WorkOS (with WorkOS FGA) ship native Zanzibar; everything else asks teams to bring OpenFGA, Authzed, or Permify alongside. Ory ships it as a first-class component.
Strict Apache 2.0 across all components avoids the licensing friction that complicates FusionAuth procurement at strict-OSS-only buyers. EU headquarters and EU data residency on Ory Network is a meaningful trust signal for European buyers wary of US data jurisdiction.
The community is large for an OSS CIAM, second only to Keycloak, with active GitHub repos, regular releases, and a CNCF-adjacent ecosystem.
Where Ory hurts
The component model imposes operational breadth. Running Kratos plus Hydra plus Keto plus Oathkeeper is four stateful services rather than one binary. Teams comfortable with Kubernetes find this fine; teams expecting a "single auth deployment" experience find it heavy. FusionAuth is the obvious lighter-ops alternative.
B2B Organizations is less first-class than dedicated B2B vendors. Multi-tenancy works through Kratos schemas and project boundaries; the Admin Portal experience is not at Frontegg's level.
Risk decisioning, adaptive MFA, and bot defense are weak. For consumer apps facing serious account-takeover pressure, pair with Authsignal or external fraud signals.
DX is improving but the component decomposition imposes a learning curve. The four-services-conceptually-distinct model is right but takes time to internalize.
How Ory compares
The closest open-source comparisons are Keycloak vs Ory for the OSS-CIAM choice and Ory vs FusionAuth for the modern-OSS pick. For SaaS migrations, Auth0 vs Ory is a common question. For EU-sovereign managed CIAM, the closest commercial alternative is Zitadel, which targets a similar buyer with a single-service architecture.
Editorial changelog (1 entry)
Full profile review: capability matrix, TCO bands, and editorial verdict re-verified against current public sources.