Ory Kratos

Last reviewed Aug 26, 2026 · 919 words

Ory Kratos is not the thing you put in front of Grafana and Nextcloud for single sign-on. It has no login page, it is not an OpenID Connect provider, and pointing an app's OIDC settings at it will get you nowhere. It is an identity API for developers building a product: registration, login, sessions, profile settings, recovery and MFA as HTTP endpoints, with the UI entirely yours. If you want SSO for a homelab, stop reading and use Authentik. If you are writing an application that needs accounts and you do not want Auth0 holding your users, keep going.

Headless means you write the login page

Kratos is built around self-service flows. Your front end asks the public API to start a login flow and receives a JSON description of the form: which fields, which methods (password, passkey, OIDC with Google, TOTP), any error messages, and a CSRF token. You render that however you like, in React, in server-side templates, in a native mobile app, and post the result back. Kratos validates, sets a session cookie or returns a session token, and your app checks /sessions/whoami on each request. The same shape covers registration, settings, verification, recovery and logout. The benefit is total control of the experience and no iframe or hosted page with someone else's branding; the cost is that every screen is your code. Ory ships a reference Node UI, kratos-selfservice-ui-node, that renders the flows generically and runs on port 4455, and it is exactly good enough to prove the setup before you replace it.

Two ports, one schema, one database

The public API listens on 4433 and is what browsers and apps talk to. The admin API on 4434 creates and edits identities, lists sessions and should never be exposed; put it on an internal network only. Identities are described by a JSON Schema you write, so "an account has an email, a display name and an optional phone number, and the email is the login identifier" is 30 lines of schema rather than a database migration. Storage is PostgreSQL in production, with MySQL and CockroachDB supported and SQLite for development, and kratos migrate sql -e --yes applies migrations before first start. A minimal kratos.yml names the database DSN, the identity schema, the public and admin base URLs, the allowed return-to URLs, and the SMTP settings for the courier that sends verification and recovery emails. Get the URLs exactly right: cookies and redirects are matched against them, and a mismatch shows up as a login that silently loops. The oryd/kratos image runs happily on the catalogue's 256 MB.

MFA and passkeys are configuration, not code

Everything under selfservice.methods is a switch. Enable totp and users can enrol an authenticator app from the settings flow; enable webauthn for security keys as a second factor, or passkey for passwordless sign-in; enable code for one-time codes by email; lookup_secret gives backup codes. Social login is the oidc method with a provider block per identity provider, using Kratos as the OIDC client, which is the one direction it does speak. The point of a headless system is that switching on passkeys does not change your front end's job: the flow JSON gains a method, your form renders it. Compare that with adding passkeys to an application that rolled its own auth table.

Kratos plus Hydra is the full picture

Kratos manages who the user is. It does not issue OAuth2 tokens or act as an OIDC provider for third-party apps. That is Ory Hydra, a separate server that delegates the actual login to whatever you built on Kratos and then hands out standards-compliant tokens. Ory Oathkeeper adds a zero-trust proxy that checks sessions in front of services, and Ory Keto handles permissions. Assemble all of them and you have what Keycloak or Zitadel give you in one binary, except decomposed, stateless and yours to style. That decomposition is either the whole appeal or the whole objection, and the catalogue's "Hard" is the right rating for the assembly, not for any one piece.

Who this is for, and who should not bother

Build on Kratos if you are shipping a product with its own accounts, you have a front end team, and you want to own identity data without owning a monolith. Pick Keycloak or Zitadel if you need OIDC and SAML for many applications today and are willing to accept their UI. Pick Authentik or Authelia if the goal is protecting self-hosted services with one login; my SSO write-up covers that case in detail, and the identity category lists the rest. Kratos has 13,800 stars and Ory's hosted Network offering runs the same code, so the open-source project is the product rather than a loss leader.

What I'd do

For any self-hosted stack: Authentik, and not a moment's thought about Kratos. For an application I was building for other people: Kratos on Postgres with the reference UI for the first week, then my own screens; password and passkey methods on, totp as second factor, code for recovery; admin API on an internal network; Hydra added the day a partner asks for "Sign in with our product" and not before. Treat the identity schema like a database schema, versioned and reviewed, because it is one.