Ory

Cloud-native open-source identity stack, Kratos (auth), Hydra (OAuth2), Keto (authorisation).

VISIT ORY

Key takeaway: Best suited to teams who want identity assembled from parts they control rather than delivered as one product. Kratos, Hydra and Keto are separate Go services you deploy and wire together, which is a strength for platform teams and a burden for everyone else. If you want one deployable and an admin console, Authentik or FusionAuth will be faster.

Quick facts

  • CategorySelf-hosted
  • LanguageGo
  • PricingOpen source
  • LicenseApache-2.0
  • Created2015
  • GitHub stars4.4k
  • HIPAA-eligibleNo
  • SSO / SAMLOut of box

What it is

Ory is a suite of cloud-native identity tools. Kratos for auth, Hydra for OAuth2 / OIDC, Keto for authorisation. Go-based, Kubernetes-friendly, OSS with a paid Ory Network cloud option. Composable, pick the parts you need.

Best for

  • Cloud-native / Kubernetes-first teams
  • Apps that want composable identity primitives over a monolithic IDP
  • Go-aligned engineering teams

When not to pick it

Skip Ory if you want a monolithic auth product, it is intentionally split into pieces. Skip if your team is not comfortable composing the suite.

My take

Ory is the right pick for cloud-native engineering teams that want composable identity. For small teams the assembly cost is real.

Composable by design, and what that costs

The split is deliberate. Kratos handles identities, self-service flows and sessions with no opinion about your UI. Hydra is an OpenID-certified OAuth2 and OIDC provider with no user management of its own. Keto implements relationship-based permissions in the style of Google's Zanzibar paper. You take only the pieces your architecture needs, and each is a small Go service with a clean API that behaves well in Kubernetes. For a platform team building an internal identity layer that many services depend on, that separation is exactly right, and Keto in particular has no real equivalent among the all-in-one products. The cost is assembly. Kratos deliberately ships no login UI, so you build one against its flow API. Wiring Kratos to Hydra for a full OAuth server is documented but is genuine integration work. Nobody reaches a working setup in an afternoon.

Self-hosted, Ory Network, and the licence

The core projects are Apache 2.0 and self-hosting them costs nothing but operations, while Ory Network is the managed service for teams who want the same model without running it. That gives a reasonable escape hatch in both directions, though moving between them is not free and the feature surfaces are not identical. The pattern worth watching, common across this part of the market, is that the open-source projects and the commercial offering compete for the same engineering attention, so verify that the specific capability you depend on is well supported in the self-hosted path rather than assuming it is. For a Go-fluent, Kubernetes-native team this is a reasonable bet. For a small product team with no platform engineers, the assembly cost is the thing that will hurt, and a single-deployable alternative is the better call.

Frequently asked questions

What is the difference between Kratos, Hydra and Keto?

Kratos manages identities, self-service flows and sessions. Hydra is an OAuth2 and OpenID Connect provider that issues tokens but does not store users. Keto handles permissions using a relationship-based model similar to Google's Zanzibar. They are separate services you deploy independently and combine only if your architecture actually needs all three.

Does Ory Kratos come with a login page?

No, and that is intentional. Kratos exposes flow APIs and expects you to build the sign-in, registration and recovery screens yourself, which gives complete control over the experience and adds real front-end work. Reference implementations exist to start from, but you own the result and everything that happens to it afterwards.

Is Ory a good fit for a small team?

Usually not. The composable architecture rewards platform teams running Kubernetes who want identity primitives under their control. A small product team spends its first weeks on assembly rather than features, and would reach a working system faster with SuperTokens, Authentik, or a hosted provider like Clerk.

Links

Similar tools you should also consider

If Ory is your pick, the next conversation is short

The 30-min call is where your auth choice becomes a real architecture, a migration plan if you are switching, and a price range you can take to your stakeholders. Describe your stack, your scale, your compliance constraints. I tell you whether Ory is genuinely your fit.