Open-source identity and access management platform. CNCF Graduate (October 2024). OIDC, OAuth 2.0, SAML 2.0, federated identity, RBAC + ABAC via Authorization Services. Originally created by Red Hat, now community-governed under the CNCF.
Keycloak is the OSS identity and access management platform that became a CNCF Graduate in October 2024 — the only mainstream OSS IdP capable of replacing commercial offerings like Okta, Azure AD, or Auth0 for self-hosted enterprise deployments. It implements OIDC, OAuth 2.0, and SAML 2.0; federates identities from LDAP, Active Directory, social IdPs, and other SAML/OIDC providers; and supports RBAC plus ABAC via Authorization Services. Originally developed by Red Hat, now governed by a multi-vendor CNCF community. The ceiling is high (Keycloak is what RHSSO is built on), but the operational floor demands real expertise — JBoss/WildFly heritage means JVM tuning, clustering, and database choices matter.
Keycloak's defining trust property is **standards-compliance over vendor convenience**. Where commercial IdPs invent proprietary 'better' protocols (Okta's Workflows DSL, Azure AD's conditional access syntax) that lock you into their ecosystem, Keycloak is uncompromisingly aligned with OIDC/OAuth 2.0/SAML standards. This makes it the rare IdP that can serve as a long-term identity infrastructure investment without vendor-lock-in risk. The trust trade-off: Keycloak gives you the standards but expects you to understand them. Teams expecting 'click here to onboard SSO' magic are better served by Okta or Auth0; teams that view identity as core infrastructure they'll operate for a decade are better served by Keycloak.
Sub-100ms token validation, OIDC discovery cached, JWT verification under 5ms with proper key rotation. Cap rule N/A (cold starts under 5s when warm-pool configured). Performance scales horizontally with load balancing; recent Quarkus distribution materially improved startup time vs the legacy WildFly base.
OIDC/SAML/OAuth 2.0 protocols are precise but not natural language. Admin console + REST API for management. Cap rule N/A — these are standard protocols, not 'proprietary query languages,' but the score reflects that natural-language interaction with the IdP is not part of its model.
Full RBAC via roles + ABAC via Authorization Services (policies, permissions, scopes with custom JavaScript or Drools rules), comprehensive audit events for every auth flow. Cap rule N/A. Keycloak's authz model is more capable than most commercial IdPs out of the box — most teams underuse it.
Multi-cloud, multi-deployment (self-hosted, RHSSO, PhaseTwo Cloud, etc.), no vendor lock-in. Cap rule N/A. Database backend is configurable (PostgreSQL, MariaDB, MS SQL Server) so the deployment isn't tied to a specific data layer either.
Federation with LDAP, Active Directory, social IdPs (Google, GitHub, Facebook, Microsoft, dozens more), SAML and OIDC brokers, custom user storage SPI for proprietary directories. Cap rule N/A. Few IdPs match Keycloak's federation breadth.
Audit events comprehensive but limited query/cost analytics compared to data systems. Cap rule N/A — cost-per-query attribution is conceptually N/A for an IdP. The 3 reflects that observability beyond audit logs requires external tooling.
G1=Y (sub-10ms ABAC via Policy Enforcement Points with cached evaluations), G2=Y (audit events cover all auth flows including login, logout, token issuance, token introspection, admin actions), G3=Y (admin console approval flows + Required Actions + identity verification flows for HITL), G4=Y (realm import/export + JSON config = Git-trackable versioning, lenient interp), G5=Y (well-documented threat model including OWASP-mapped security features and known-attack mitigations), G6=Y (deployment guides for HIPAA, FedRAMP, SOC 2 patterns). 6/6 -> 5.
O1=Y (Micrometer metrics integrate with Prometheus/Datadog/Grafana out of the box), O2=Y (OpenTelemetry support for distributed tracing of auth flows), O3=N (LLM cost tracking N/A for IdP), O4=Y (MTTD <10min achievable with Prometheus + alertmanager), O5=N (no drift detection in product — that's an external concern), O6=N (not an AI decisioning system). 4/6 -> 4.
A1=Y (sub-2s p95 token validation comfortably), A2=Y (real-time auth, no batch lag), A3=Y (token caching well-tuned, OIDC discovery cache effective), A4=Y (HA cluster with shared DB and Infinispan distributed cache achieves 99.9%+), A5=N (rarely 10x-tested by most teams, capacity planning is operational), A6=Y (parallel auth flows, multi-realm isolation). 5/6 -> 4.
L1=Y (user federation with attribute mappers normalize identities across LDAP/AD/social/OIDC sources), L2=Y (claim dictionary via mapper attributes, lenient interp — Keycloak doesn't have an explicit business glossary but the realm attribute model functions similarly), L3=N (no NL disambiguation), L4=N (no continuous learning from user behavior — auth is rule-based), L5=Y (claim mappers normalize terminology across federated sources, e.g. 'mail' vs 'email' vs 'preferred_username' all map to a canonical attribute), L6=N (no human evaluation surface for auth decisions). 4/6 -> 4.
S1=Y (deterministic auth — same credentials produce same outcome), S2=Y (typed user attributes with validators), S3=Y (federation maintains consistency between source IdP and Keycloak's user store via periodic sync), S4=Y (user attribute validators enforce schema), S5=Y (auth flow stages with required actions enforce quality gates: credential check + 2FA + consent + final approval), S6=N (basic brute-force detection via login failure tracking, but not ML-based anomaly detection). 5/6 -> 4.
Best suited for
Compliance certifications
Keycloak the project does not hold compliance certifications. Compliance comes from your deployment: Red Hat Single Sign-On (commercial Keycloak with Red Hat support, has separate certifications), self-hosted on FedRAMP-authorized infrastructure (AWS GovCloud, Azure Gov), HIPAA-compliant deployments using a BAA-signing cloud provider for the underlying compute and database. The CNCF project doesn't sign BAAs or hold third-party audit reports. PhaseTwo Cloud and other managed-Keycloak services may carry their own attestations.
Use with caution for
Choose Azure AD for Microsoft-stack enterprises wanting deep integration with Microsoft Graph, Conditional Access, and Office 365. Keycloak wins on standards-compliance and self-hosted data sovereignty; Azure AD wins on managed-service operations (zero JVM tuning) and Microsoft ecosystem integration. Most enterprises end up with both — Azure AD as primary employee IdP, Keycloak as customer-facing or partner IdP.
View analysis →AWS IAM is for AWS service-to-service authorization and AWS user management — different use case from Keycloak's external-facing IdP. AWS IAM Identity Center (formerly SSO) is closer but still AWS-centric. Choose Keycloak for cross-platform identity that needs to work outside AWS resources; choose IAM Identity Center for AWS-native employee SSO without standing up a Keycloak cluster.
View analysis →Role: L5 identity provider and authorization substrate. Issues OAuth 2.0 / OIDC tokens, federates external identities, enforces RBAC + ABAC at the auth layer. The trust boundary for user and service identity across the agent stack.
Upstream: Receives user provisioning from HRIS systems (via SCIM), federated identities from corporate directories (LDAP, AD), social logins from external IdPs. Configuration via realm JSON in Git.
Downstream: Issues access tokens to L4 agents, identity claims to L5 policy engines (OPA, Cedar), audit events to L6 observability stack, OIDC discovery endpoints to all consumers.
Mitigation: Deploy 3+ node cluster with shared PostgreSQL + Infinispan distributed cache. Test failover with a planned reboot and measure RTO. Configure session replication appropriately for your tolerance to lost sessions on failover.
Mitigation: Use Keycloak's Policy Evaluation API to write automated tests for policy decisions. Simulate cross-tenant queries, edge cases (deleted users, expired tokens, unusual claim combinations). Without tests, policy changes silently regress in production.
Mitigation: Export realms as JSON, commit to Git, apply via CI/CD or Terraform Keycloak provider. Manual UI changes in production are the #1 source of staging/prod divergence in IdP deployments.
Mitigation: Rotate default credentials immediately. Restrict /auth/admin to internal networks via reverse proxy or service mesh. Enable MFA for admin accounts. Use service accounts (with tightly-scoped roles) for automation, not the root admin user.
Mitigation: Prefer Drools or built-in policy types over custom JavaScript when possible. If you must write JS, code-review every policy and run them through a sandbox. JS policies execute in the same JVM as Keycloak.
Mitigation: Test version upgrades in staging with production-sized data. Some upgrades require explicit DB migrations that take minutes per million users. Plan upgrade windows and use blue-green or canary deployments.
Keycloak's federation with social IdPs + Required Actions for email verification + custom auth flows for magic links handle this cleanly. Realm-per-environment gives clean staging/prod separation.
Each tenant gets their own realm with their own SAML/OIDC broker. Tenants self-onboard via Keycloak admin API. Authorization Services enforce tenant isolation at the auth layer.
AWS IAM Identity Center is simpler and AWS-managed. Keycloak adds operational burden without significant benefit for pure AWS-internal use cases. Use Keycloak when you have non-AWS resources to integrate.
Auth0, Clerk, WorkOS get you there in hours. Keycloak takes weeks to deploy correctly. Choose Keycloak when identity is core infrastructure you'll operate for a decade, not a feature you need shipped this week.
This analysis is AI-generated using the INPACT and GOALS frameworks from "Trust Before Intelligence." Scores and assessments are algorithmic and may not reflect the vendor's complete capabilities. Always validate with your own evaluation.