Kanidm

Last reviewed Sep 13, 2026 · 967 words

Kanidm will not start over plain HTTP, and it does not want your users to have passwords at all. Both facts are deliberate. It is an identity server written in Rust (5,300 stars, MPL-2.0, first released 2019) that treats passkeys as the primary credential, serves OAuth2 and OpenID Connect to your web apps and LDAP to everything older, and runs in around 256 MB of RAM as a single process with a single data file. The trade-off is that it is opinionated, expects you at a command line, and has a smaller ecosystem than the projects most people install first. This guide is about deciding whether that trade suits you before you spend a weekend on it.

Why a homelab would pick it over Authentik

Authentik is the default self-hosted SSO for good reasons: a web admin, forward-auth for apps with no login of their own, and a very large set of worked integrations. It also runs on a Postgres database, a Redis, a worker, and a server, and idles above 1 GB. Kanidm is the opposite shape: one binary, one SQLite-backed database, no web admin beyond a self-service account page, and everything configured through the kanidm CLI. It uses less memory than Authelia, which is the light option in the Authentik vs Authelia matchup, and does far more than Authelia, because it is a real directory, not just a login gate.

The people who run Kanidm well are the ones who also want it to be the identity source for their Linux machines. Its kanidm-unixd daemon provides PAM and NSS integration, so a user created in Kanidm can log into every server, SSH with keys stored in the directory, and be removed everywhere with one command. Authentik does not do that. If your goal is "one login for six Docker web apps", Authentik is the safer pick. If it is "one directory for web apps, SSH, and LDAP-speaking services with the strongest credentials available", Kanidm is the better design.

TLS first, because there is no HTTP mode

Kanidm binds HTTPS on 8443 and LDAPS on 3636, and needs a certificate and key before it will boot. For a homelab that means either a real certificate from your reverse proxy's ACME flow copied into the volume, or an internal CA you trust on your clients. The server config is small:

# /data/server.toml
bindaddress = "[::]:8443"
ldapbindaddress = "[::]:3636"
domain = "idm.example.com"
origin = "https://idm.example.com"
tls_chain = "/data/chain.pem"
tls_key = "/data/key.pem"
db_path = "/data/kanidm.db"

domain is baked into every WebAuthn credential your users register. Change it later and every passkey stops working, so pick the final hostname on day one. Run the kanidm/server container with /data mounted, then recover the built-in accounts:

docker exec -it kanidm kanidmd recover-account admin
docker exec -it kanidm kanidmd recover-account idm_admin

admin manages the server, idm_admin manages people and groups; the split is intentional and you will use idm_admin far more.

Everything is a CLI command, and that is fine

Creating a person, giving them a passkey, and wiring an app to OIDC:

kanidm person create aidan "Aidan Murphy" --name idm_admin
kanidm person credential create-reset-token aidan --name idm_admin
kanidm group create grafana-users --name idm_admin
kanidm group add-members grafana-users aidan --name idm_admin
kanidm system oauth2 create grafana "Grafana" https://grafana.example.com --name idm_admin
kanidm system oauth2 update-scope-map grafana grafana-users openid profile email --name idm_admin
kanidm system oauth2 show-basic-secret grafana --name idm_admin

The reset token gives a link the user opens to enrol a passkey or set a password in the self-service page. Passkeys are the intended path; passwords exist and Kanidm enforces length and breach checks on them. Groups map to OAuth2 scopes, so app access is a group membership, which is how it should be. There is no forward-auth mode: apps have to speak OIDC or LDAP themselves. For the usual pattern of protecting a login-less app behind a proxy, you would still need a small forward-auth component in front, or a different product.

LDAP is read-only and that is the right call

The LDAPS listener on 3636 exists so that services which only understand LDAP (some mail servers, older wikis, a NAS) can authenticate against the same accounts. It is read-only, exposes a simplified schema, and uses a per-service bind account rather than your admin credentials. If you need writable LDAP with custom object classes, LLDAP covers the simple case and a heavier server covers the rest.

Backups and the ecosystem gap

One file, kanidm.db, plus the certificates. The server has an online backup command and a config option for scheduled backups to a directory; enable it and copy that directory off-host. The gap you will feel is documentation for third-party apps: where Authentik or Keycloak have a tested integration page for nearly everything, with Kanidm you are reading the generic OIDC section of each app's docs and figuring out claim names yourself. It works; it is just quieter.

What I'd do

Pick Kanidm if you administer Linux boxes and want your directory to cover them, you are comfortable with a CLI-only admin experience, and you want passkeys rather than tolerating them. Set the domain correctly once, keep the TLS material in the volume, and start with 2 or 3 OIDC apps before migrating the rest. If your identity needs stop at web apps and you want a clicking interface and forward-auth, install Authentik instead and accept the extra gigabyte; the identity category is one where the popular choice is popular for real reasons.