Keycloak

What it is

Keycloak is an open-source identity and access management (IAM) server. It handles authentication, authorization, single sign-on (SSO), user federation (LDAP/AD), and social login, speaking OIDC, OAuth2, and SAML 2.0 out of the box. Since v18 it runs on Quarkus, which cut startup time and memory footprint significantly versus the old WildFly-based distribution. You deploy it as the auth layer in front of your apps and APIs instead of building login/token/session logic yourself.

The "Provisioning" category tag here is a bit loose — Keycloak is fundamentally an identity provider, not an infra provisioning tool. Treat it as IAM/AuthN-AuthZ infrastructure.

Who builds it and why

Originated at Red Hat, now a CNCF incubating project with community governance. 1,848 contributors and steady commit activity (last commit within days of writing) indicate this isn't a corporate side project on life support — it's actively maintained with a real contributor base beyond Red Hat employees. Red Hat's commercial interest is Red Hat build of Keycloak (RHBK), their supported downstream, which funds a chunk of upstream development. That's a healthy incentive structure: Red Hat needs upstream to stay good to sell support on top of it.

Production readiness signal

CNCF incubating status means it's cleared graduation bar checks for governance, adoption, and security practices, but hasn't hit the highest maturity tier (like etcd or Kubernetes itself). In practice, Keycloak has been running in production at scale for years — it predates its CNCF entry by a long stretch and was battle-tested inside Red Hat SSO before that.

35,450 GitHub stars and 1,848 contributors are solid adoption signals. Release cadence is frequent (26.6.4 as latest), and the Quarkus migration was a serious engineering effort that paid off in performance and clustering behavior. Apache-2.0 license, no vendor lock-in on the license side.

Real-world caveat: Keycloak clustering (Infinispan-based) has historically been the rough edge — cross-datacenter replication and cache tuning under high load require real expertise. Budget time for this if you're running multi-region.

Who should use this

• Teams that need a self-hosted, standards-compliant IdP and don't want to pay per-MAU to Auth0/Okta.
• Organizations with existing LDAP/AD that need federation plus modern OIDC/SAML in front of it.
• Platform teams building internal developer platforms who want SSO across many internal tools without vendor pricing scaling with headcount.
• Anyone already running Kubernetes/Java-heavy infra who's comfortable operating a JVM service and doesn't mind owning uptime for critical auth infrastructure.

Who should NOT use this

• Small teams without dedicated ops capacity — Keycloak is not "install and forget." Upgrades, clustering, and cache tuning require real ongoing attention.
• Teams needing enterprise support SLAs without an internal team to operate it — go pay for RHBK, Okta, or Auth0 instead of learning IAM internals under pressure.
• Greenfield projects wanting the fastest possible time-to-auth with minimal config — managed IDaaS will get you there faster.
• High-compliance environments (FedRAMP, specific SOC2 addendums) where you need vendor-backed audit trails and support contracts baked in from day one — use a commercial IdP with those certifications already done.

Alternatives

• Auth0 — managed IDaaS, faster to start, pricing scales with MAU and can get expensive at scale.
• Ory (Kratos/Hydra) — more modular, API-first, cloud-native identity stack; steeper assembly required but less monolithic than Keycloak.
• Okta — enterprise-grade managed IAM with strong compliance certifications; higher cost, less control over internals.

Pricing

Fully open source under Apache-2.0. No license fees, no MAU-based pricing. You pay in infrastructure and ops time to run it yourself, or you buy commercial support (e.g., Red Hat build of Keycloak) if you want a vendor on the hook.