Kanidm

Self-hosted identity management, honestly reviewed. No marketing fluff, just what you get when you run your own authentication stack.

TL;DR

• What it is: Open-source (MPL-2.0) identity management platform written in Rust — think a single self-hosted replacement for Okta, JumpCloud, or the messy Keycloak + LDAP combination most sysadmins end up with [README].
• Who it’s for: Homelabbers, small businesses, and engineering teams who want to run their own SSO, passkeys, RADIUS, and Linux user management without stitching together five separate tools. Not for non-technical founders who won’t touch a terminal [1][README].
• Cost savings: Okta runs $2–8/user/month. JumpCloud starts at $9/user/month. Azure AD is bundled with Microsoft 365 at roughly $6+/user/month. Kanidm self-hosted runs on a $6–10/mo VPS with no per-user licensing [README].
• Key strength: Unusually complete feature set in a single binary — passkeys, OAuth2/OIDC, RADIUS, SSH key distribution, Linux PAM/NSS integration, and read-only LDAP gateway, all without external dependencies like Keycloak [README][1].
• Key weakness: Administration is entirely CLI-based. There is no web admin panel — the web UI exists only for user self-service, not for managing users, groups, or applications [1]. If your team expects a point-and-click admin interface, look elsewhere.

---

What is Kanidm

Kanidm (pronounced “kar-nee-dee-em”) is an identity management platform that lets you run your own authentication service. Other applications — your wiki, your VPN, your Linux servers, your internal web apps — offload user authentication to Kanidm rather than managing their own credentials [README].

The project describes its goal plainly: “You should not need any other components (like Keycloak) when you use Kanidm — we already have everything you need” [README]. That’s the pitch in one sentence. Instead of deploying Keycloak for SSO, then an LDAP server for Linux logins, then a RADIUS server for VPN, and then wiring them all together, Kanidm handles the whole stack.

It’s written in Rust, which buys you memory safety and performance without a JVM or Python runtime. The project sits at 4,704 GitHub stars as of this writing [merged profile], well behind Authelia or Authentik in terms of community visibility, but meaningfully ahead in built-in feature breadth. The license is MPL-2.0 — source-available, but not fully permissive; commercial embedding in a proprietary product requires attention to the license terms, unlike an MIT tool [merged profile].

The name is a Rust joke: “kani” is Japanese for crab, and Rust’s mascot is Ferris the crab. Identity management is abbreviated to “idm.” The project’s unofficial anthem is Crab Rave. This is as good a sign as any that the developers are both serious about their work and don’t take themselves too seriously [README].

---

Why people choose it

The third-party coverage on Kanidm is thinner than for Authentik or Keycloak — the tool hasn’t crossed the threshold where it gets dozens of “honest review” posts. What does exist points to a consistent pattern.

The all-in-one pitch is genuine. William Lam at williamlam.com, who has set up vCenter identity federation with Authentik, KeyCloak, Synology SSO, Pocket ID, and Zitadel, tested Kanidm specifically because a colleague had success with it and recommended it [1]. The fact that an experienced infrastructure person is expanding their IdP collection to include Kanidm suggests the feature set is credible. His writeup covers the setup steps in detail without major complaints about the process — notable, because his posts on Keycloak and Authentik both mention complexity.

Passkeys are first-class. Kanidm was building WebAuthn support before most IdPs treated it as a priority. The README distinguishes between regular passkeys and “attested passkeys for high security environments” [README]. For teams that want to get off passwords entirely, this is a genuine advantage over tools that added passkey support as an afterthought.

Linux integration is unusually deep. SSH key distribution to Linux/Unix systems, PAM and NSS integration with TPM-protected offline authentication, RADIUS for network and VPN — this is the combination that sysadmins running a fleet of Linux machines actually need, and it’s rarely found in one package [README][4]. Tools like Authentik cover OAuth2/OIDC well but don’t natively handle the RADIUS-for-VPN use case.

The CLI-only admin model divides opinion. Source [1] notes explicitly: “what makes this IdP unique is that it is completely managed using a CLI, there is no web interface like ones listed above.” For engineers, this can be a feature — reproducible, scriptable, diffable administration. For anyone who expected a web admin panel, it’s a dealbreaker. Know which camp you’re in before deploying.

---

Features

Based on the README and primary documentation:

Authentication methods:

• Passkeys (WebAuthn) — regular and attested, for high-security environments [README]
• TOTP (Time-based One-Time Passwords) via authenticator apps like Google Authenticator [1]
• Traditional username/password with MFA enforcement [1]
• SSH key pairs distributed to Linux/Unix systems [README]

SSO and application integration:

• OAuth2/OIDC provider for web application SSO [README]
• OAuth2 token exchange services [README]
• Application Portal — a dashboard that lists linked applications for end users, so they have one place to find everything [README]
• Read-only LDAPs gateway for legacy systems that speak LDAP and can’t be updated [README]

Infrastructure integration:

• Linux/Unix PAM and NSS integration (users can log into Linux servers using Kanidm identities) [README]
• TPM-protected offline authentication — Linux logins still work when the Kanidm server is unreachable [README]
• RADIUS for network authentication and VPN [README]
• SSH key distribution — push SSH public keys from Kanidm to Linux servers without managing authorized_keys files manually [README]

Operations:

• Complete CLI tooling for all administrative tasks [README][1]
• WebUI for user self-service (password changes, MFA enrollment, profile) — not for admin [README][1]
• Two-node high availability using database replication [README]
• Self-healing components — the project explicitly emphasizes automatic recovery from inconsistent states [README]
• Strict defaults — the philosophy is that safe behavior should require no extra configuration [README]

What’s missing (or not documented):

• No SCIM provisioning mentioned in documentation
• No audit log or SIEM integration mentioned prominently
• SAML support is not listed (OAuth2/OIDC only for federation)
• No web-based admin interface [1]

---

Pricing: SaaS vs self-hosted math

Kanidm has no commercial tiers, no SaaS offering, and no per-user pricing. It’s free software. The only costs are infrastructure.

Self-hosted Kanidm:

• Software: $0 (MPL-2.0) [README]
• VPS: $6–15/month depending on provider and instance size
• Your time to set it up

What you’d replace:

Tool	Pricing
Okta (Workforce Identity)	$2–8/user/month; 50 users = $100–400/month
JumpCloud	$9/user/month; 50 users = $450/month
Auth0	Free up to 7,500 MAUs, then $23+/month scaling by usage
Azure Active Directory	~$6/user/month as a standalone product
Authentik (SaaS)	Not available; self-hosted only

For a company with 20–50 employees paying Okta or JumpCloud, the math is straightforward. At $9/user/month on JumpCloud with 30 users, you’re at $270/month, $3,240/year. A Kanidm deployment on a $10/month VPS costs $120/year. The savings are obvious. What’s less obvious is the total cost of administration time — Kanidm requires someone comfortable with the CLI for every user and application management task.

For solo developers or homelabbers, the comparison is simpler: Okta’s free tier covers 100 MAUs but lacks the Linux integration and RADIUS that Kanidm offers. The only cost is setup time.

---

Deployment reality check

Deployment follows a Docker-based path. William Lam’s walkthrough [1] is the most detailed public deployment guide available and covers the steps clearly:

1. Generate TLS certificates (self-signed is fine for testing, required for production-grade)
2. Write a server.toml configuration file with bind address, database path, TLS cert paths, domain, and origin
3. Pull and create the Docker container, copy configuration files and certificates into the container
4. Run configtest to validate the configuration
5. Start the container
6. Recover the auto-generated admin and idm_admin passwords from the container logs
7. Create a client configuration file at ~/.config/kanidm pointing at your instance
8. Log in with the CLI and begin configuration

There is no web-based setup wizard. Every subsequent action — creating users, creating OAuth2 clients, assigning groups, configuring RADIUS — happens through the kanidm CLI client [1][README].

Realistic time estimates:

• Experienced Linux/Docker user: 1–2 hours to a working instance
• Someone following a guide carefully for the first time: 3–5 hours including TLS setup and first OAuth2 client
• Non-technical user without command-line experience: not recommended without a technical person to deploy and administer it

What can go sideways:

• TLS is mandatory. Kanidm will not run without a valid TLS configuration — this is a security decision, but it trips up people expecting to start with HTTP [1]
• The TOTP requirement: if you enable password authentication, Kanidm requires TOTP enrollment. This is security by design, but it means every user must set up an authenticator app — there’s no bypass for internal tools where MFA feels like overkill [1]
• The CLI-only admin model: every future user addition, group change, or OAuth2 client configuration requires SSH access to a machine with the kanidm CLI and the client configuration file. If you lose the admin credentials, recovery requires Docker exec access to the container [1]
• Two-node HA is documented but adds setup complexity. Single-node is fine for most small deployments but loses the recovery guarantees [README]

---

Pros and Cons

Pros

• Complete identity stack in one binary. OAuth2/OIDC, LDAP gateway, RADIUS, SSH key distribution, Linux PAM/NSS, passkeys — without external dependencies or component stitching [README].
• Passkeys from the start. WebAuthn is a core feature, not an add-on. Attested passkeys for high-security environments are explicitly supported [README].
• Rust performance and safety. No JVM startup time, no Python memory behavior, no garbage collection pauses during authentication — relevant when Kanidm sits in the critical path of every login [README][4].
• Linux fleet integration. TPM-protected offline auth and SSH key distribution are capabilities that most IdPs don’t offer or require third-party agents to achieve [README].
• Self-healing and strict defaults. The project philosophy of defaulting to safe behavior and recovering from inconsistent state reduces operational risk [README].
• No per-user licensing. Add 500 users or 5 — the cost stays the same [README].
• Two-node HA built in. No external clustering solution required for basic redundancy [README].
• MPL-2.0 is source-available. You can read, audit, and modify the code. You’re not running a black box [merged profile].

Cons

• No web admin interface. Every administrative action requires the CLI. This is a deliberate design choice, not a gap that will be filled — the web UI is user-facing only [1][README].
• Small community relative to alternatives. 4,704 GitHub stars compared to Authentik’s 15,000+ or Keycloak’s 25,000+. Fewer community guides, fewer integrations documented, fewer people to ask when something breaks [merged profile].
• MPL-2.0, not MIT or Apache-2.0. If you want to embed Kanidm components in a commercial product, the license requires more attention than the permissive alternatives [merged profile][4].
• No SAML support. Modern enough if everyone in your stack speaks OIDC, a problem if you need to integrate legacy enterprise applications that speak SAML only [README].
• TOTP is non-optional for password auth. Security-forward, but operationally inconvenient for internal tooling where MFA feels excessive [1].
• TLS is mandatory at setup. Reasonable for a security tool, but slows down initial local testing [1].
• Limited third-party reviews. Unlike Authentik or Keycloak, there are few independent “I ran this in production for 6 months” posts. The risk profile of running an identity provider with limited community validation is higher than for more established tools.

---

Who should use this / who shouldn’t

Use Kanidm if:

• You’re an engineer or sysadmin comfortable with the CLI for all administrative tasks.
• You’re running a Linux fleet and want SSH key distribution, PAM integration, and RADIUS in one package without stitching tools together.
• You want passkeys as a first-class authentication method, not bolted on.
• You’re replacing a commercial IdP (Okta, JumpCloud) and the per-user cost is painful.
• You value strict defaults and want an identity provider that doesn’t require you to know exactly which security settings to enable.
• You’re running a homelab or small business where one technical person owns the infrastructure.

Skip it (pick Authentik instead) if:

• You need a web-based admin panel — Authentik has one, Kanidm doesn’t.
• You want a large community, abundant tutorials, and a long history of production deployments.
• You need SAML support for enterprise application federation.
• Your team has non-technical people who will ever need to add users or configure applications.

Skip it (pick Keycloak instead) if:

• You need enterprise feature depth: fine-grained authorization policies, user federation from multiple LDAPs, complex authentication flows, and a 15-year community behind it.
• You need SAML 2.0 extensively.
• You’re in a large organization where the complexity trade-off favors Keycloak’s configurability.

Skip it (pick a managed service) if:

• You don’t have someone technical who can administer CLI-only tooling.
• Your compliance team won’t approve self-hosted infrastructure for identity data.
• The time to deploy and maintain a self-hosted IdP costs more than Okta’s monthly bill.

---

Alternatives worth considering

• Authentik — the most comparable self-hosted IdP in terms of feature breadth. GPL-3.0, has a web admin panel, larger community, better SAML support. More complex to configure, heavier resource usage. If you want a web admin UI, start here.
• Keycloak — the enterprise standard. Java-based, Apache-2.0, enormous feature set, large community. Configuration complexity is its main complaint; requires significant expertise to tune properly. Relevant if you need SAML and complex policy flows.
• LLDAP — the “just LDAP” option. Much simpler than Kanidm, web UI for administration, but requires adding Keycloak or Pocket ID separately for OAuth2/OIDC. The Kanidm README explicitly compares them: choose LLDAP if you only need LDAP and want simplicity, choose Kanidm if you want the complete IdP stack [README].
• Pocket ID — newer, extremely lightweight, OIDC-only. Good for simple passkey-based SSO use cases. Not a replacement for Kanidm’s RADIUS and Linux integration.
• Zitadel — Apache-2.0, Go-based, cloud-native design, good API, has a web admin UI. More SaaS-architecture oriented; less focus on the Linux fleet integration that Kanidm prioritizes.
• FreeIPA — the traditional Linux-native IAM platform. Mature, production-proven, but notorious for installation complexity and a heavyweight dependency stack (Dogtag CA, 389-ds, Kerberos). Kanidm is targeting the same use case with a much simpler deployment story.

For the Okta/JumpCloud replacement use case specifically, the realistic shortlist is Kanidm vs Authentik. Choose Kanidm if you want CLI-driven administration and deep Linux fleet integration. Choose Authentik if you want a web admin panel and broader community support.

---

Bottom line

Kanidm is the most technically complete single-binary identity provider in the self-hosted space — passkeys, OAuth2/OIDC, RADIUS, SSH key distribution, Linux PAM/NSS, and read-only LDAP, all without external dependencies. For an engineering team or technically capable sysadmin running a Linux fleet, the per-user-licensing math against Okta or JumpCloud is obvious, and the feature breadth argument against LLDAP + Keycloak is real. The trade-offs are also real: CLI-only administration with no web panel, a smaller community than Authentik or Keycloak, no SAML support, and mandatory TLS from the start. This is a tool built by security-focused engineers for technical operators. If that’s you, the Rust-native performance and strict-by-default security posture are genuinely attractive. If you need a point-and-click admin interface or your non-technical co-founder will ever touch it, look at Authentik first.

If the deployment and ongoing administration are the blockers, that’s exactly what upready.dev handles for clients — one-time setup, you own the infrastructure.

---

Sources

1. William Lam — “vCenter Server Identity Federation with Kanidm” (Apr 2025). https://williamlam.com/2025/04/vcenter-server-identity-federation-with-kanidm.html
2. Tux Machines / LinuxLinks — “Kanidm – simple and secure identity management” (Sep 01, 2025). https://news.tuxmachines.org/n/2025/09/01/Kanidm_simple_and_secure_identity_management.shtml
3. Wener Live & Life — “Auth Awesome” — curated IAM/SSO reference including Kanidm. https://wener.me/notes/service/auth/awesome
4. Awesome Open Source — “Cloudsplaining Alternatives” — Kanidm listed as MPL-2.0 Rust IAM platform. https://awesomeopensource.com/project/salesforce/cloudsplaining

Primary sources:

• GitHub repository and README: https://github.com/kanidm/kanidm (4,704 stars, MPL-2.0 license)
• Official website: https://kanidm.com
• Kanidm Book (documentation): https://kanidm.github.io/kanidm/stable/