ZITADEL vs Keycloak vs Authentik: cuál elegir para un SaaS B2B
Keycloak es el estándar histórico, rico en funciones y respaldado por Red Hat. Su problema para un VPS self-hosted: la JVM. En reposo, Keycloak consume entre 512 MB y 1 GB de RAM, y cada realm es un árbol de configuración separado que mantener. La semana 38 de 2026 ilustró el riesgo: seis CVEs corregidas en dos releases consecutivas, incluidos dos DoS no autenticados en los endpoints SAML y de login.
Authentik (2026.8.2) es la elección natural para equipos que quieren un IdP completo con interfaz gráfica, flujos visuales y provisionamiento SCIM. Está escrito en Python/Django y requiere al menos 1 GB de RAM utilizable.
ZITADEL (v2.x, Go) es el único de los tres que diseñó el multi-tenancy como primitiva de primera clase. Una instalación única expone organizaciones independientes — cada cliente obtiene su espacio aislado sin duplicación de configuración. Para una agencia que aloja diez clientes en un único VPS, es la diferencia entre diez archivos de configuración de Keycloak y una API que lo orquesta todo.
Por qué ZITADEL destaca para uso en agencias y SaaS B2B
- Multi-tenancy nativo: organizaciones y proyectos son primitivas del modelo de datos, no soluciones alternativas — cada cliente obtiene un espacio aislado sin duplicación de configuración
- Escrito en Go: binario único, inicio en segundos, huella de memoria de 150 a 300 MB stack completo frente a 512 MB a 1 GB de JVM
- OIDC, OAuth2, SAML 2.0 y LDAP: todos los protocolos empresariales en una sola instalación
- Passkeys y WebAuthn nativos desde v2: cada organización puede imponer Passkeys como único factor de autenticación sin plugins
- API-first gRPC/REST: toda operación disponible en la consola lo está también vía API — provisionar un tenant o crear una aplicación OIDC en pocas líneas de script
- Acciones (webhooks/código): lógica personalizada disparada en eventos de autenticación sin modificar el core
- Despliegue sin estado de aplicación: ZITADEL almacena todo en PostgreSQL — sin caché distribuida, sin volúmenes adicionales
- Licencia Apache 2.0: el núcleo es completamente open source sin funciones críticas ocultas tras una licencia Enterprise
Prerequisitos: servidor, Docker y DNS
La configuración mínima recomendada por el equipo para un despliegue en producción es 2 vCPU y 4 GB de RAM — de los cuales unos 300 MB serán utilizados por ZITADEL mismo, el resto yendo a PostgreSQL y otros servicios.
Software requerido: Docker Engine 24+ y Docker Compose v2. Los puertos 80 y 443 deben estar abiertos (nginx terminará el TLS). Un nombre de dominio apuntando a la IP de tu VPS — ZITADEL requiere un FQDN incluso en desarrollo, ya que las cookies OIDC están vinculadas al dominio.
Base de datos: PostgreSQL 15 o 16. ZITADEL también soporta CockroachDB para despliegues de alta disponibilidad, pero en un VPS de un único nodo, PostgreSQL es la elección natural.
Desplegar ZITADEL con Docker Compose y PostgreSQL
Crear la estructura de directorios
Conéctate a tu VPS por SSH y crea los directorios necesarios:
mkdir -p /opt/zitadel/{config,certs} cd /opt/zitadelCrear el archivo .env con los secretos
cat > /opt/zitadel/.env <<EOF POSTGRES_PASSWORD=$(openssl rand -base64 32 | tr -d '\n') ZITADEL_MASTERKEY=$(openssl rand -base64 32 | tr -d '\n' | head -c 32) ZITADEL_DOMAIN=sso.tu-dominio.com EOFEl
MASTERKEYdebe tener exactamente 32 caracteres.Escribir el docker-compose.yml
Crea
/opt/zitadel/docker-compose.ymlcon los servicios PostgreSQL y ZITADEL, configurando la conexión a la base de datos mediante variables de entorno y exponiendo el puerto 8080 para nginx.Configurar nginx como reverse proxy TLS
Crea un bloque de servidor nginx para
sso.tu-dominio.comque redirija HTTP a HTTPS y proxee las peticiones ahttp://127.0.0.1:8080. Establece la cabeceraX-Forwarded-Proto: https. Obtén el certificado Let's Encrypt con Certbot.Iniciar el stack ZITADEL
cd /opt/zitadel docker compose up -d docker compose logs -f zitadelEspera el mensaje
server is listening on [::]:8080en los logs — generalmente tarda de 30 a 60 segundos.Recuperar las credenciales de administrador iniciales
docker compose logs zitadel 2>&1 | grep -A 5 'initial'Las credenciales se muestran solo una vez. Guárdalas en tu gestor de secretos.
Iniciar sesión en la consola de administración
Abre
https://sso.tu-dominio.com/ui/consoleen un navegador. Inicia sesión con las credenciales recuperadas en el paso anterior.Crear tu primera organización cliente
En la consola, ve a Organización → Nueva organización. Dale el nombre de tu cliente. ZITADEL crea automáticamente un espacio aislado — los usuarios de esta organización no pueden ver los de las demás.
Crear un proyecto y una aplicación OIDC
En la organización, ve a Proyectos → Nuevo proyecto. Crea una Aplicación web de tipo OIDC. ZITADEL te pedirá el tipo de cliente y las URLs de redirección. Generará un
Client IDy unClient Secret.Verificar el estado y fijar la versión de la imagen
curl -s https://sso.tu-dominio.com/healthz | jq .Una respuesta
{"status": "pass"}confirma que ZITADEL responde correctamente. Fija la etiqueta de versión endocker-compose.yml—stablesigue el último release, lo que puede introducir cambios no planificados en producción.
Configurar la autenticación OIDC para tus aplicaciones
Una vez ZITADEL en marcha y una aplicación OIDC creada, la configuración del lado del cliente es estándar — cualquier biblioteca OIDC (passport.js, next-auth, python-oidc, etc.) funciona sin adaptación específica de ZITADEL.
Parámetros OIDC esenciales:
ISSUER=https://sso.tu-dominio.com
CLIENT_ID=<client_id_generado>
CLIENT_SECRET=<client_secret_generado>
REDIRECT_URI=https://tu-app.com/callback
SCOPES=openid profile emailEl Discovery Document está disponible en https://sso.tu-dominio.com/.well-known/openid-configuration. Para SPAs (React, Vue), usa el flujo PKCE sin secreto en el lado del cliente.
Modelo multi-tenant: organizaciones, proyectos y aplicaciones
El modelo de datos de ZITADEL se articula en tres niveles que corresponden exactamente a las necesidades de una agencia o SaaS B2B.
La organización es el contenedor de un tenant. Cada organización tiene sus propios usuarios, sus propios IdP externos y sus propias políticas de contraseña. Puede ser administrada por un delegado de la organización — tu cliente — sin que eso le dé acceso a las demás organizaciones.
El proyecto agrupa las aplicaciones de un único producto. Un proyecto puede contener una aplicación web, una aplicación móvil y una API — todas compartiendo los mismos roles y permisos, definidos una sola vez a nivel de proyecto.
La aplicación representa un cliente OIDC, OAuth2 o SAML específico. Este modelo permite a una agencia gestionar diez clientes en una única instalación de ZITADEL sin ningún riesgo de contaminación entre tenants.
ZITADEL vs Authentik vs Keycloak — comparativa técnica
Desplace la tabla
| Criterio | ZITADEL v2.x | Authentik 2026.8 | Keycloak 26.7 |
|---|---|---|---|
| Lenguaje / runtime | Go — binario único | Python + Rust (frontend) | Java (JVM) |
| RAM stack completo (reposo) | 150 – 300 MB | ~1 GB (worker + PostgreSQL) | 512 MB – 1 GB (solo JVM) |
| Multi-tenancy nativo | Sí — primitiva Organizaciones | Parcial — tenants separados | Parcial — realms separados |
| OIDC / OAuth2 / SAML | Sí — los tres nativos | Sí — los tres nativos | Sí — los tres nativos |
| Passkeys / WebAuthn | Sí, nativo v2 | Sí (2026.2+) | Sí (v21+) |
| API-first | gRPC + REST, cobertura 100% | REST parcial | REST parcial |
| Interfaz de administración | Consola web + API | UI completa con flujos visuales | UI completa, configuración XML |
| Licencia | Apache 2.0 (núcleo) | MIT (Community) / Enterprise | Apache 2.0 |
Activar Passkeys y MFA en ZITADEL v2
ZITADEL v2 ofrece Passkeys WebAuthn como factor de autenticación principal — no solo como segundo factor. Para activarlos en una organización:
1. En la consola, abre Organización → Política de seguridad → Política MFA
2. Activa Passkeys (WebAuthn sin contraseña) y selecciona Forzar si quieres que todos los usuarios de esta organización utilicen únicamente Passkeys
3. Para una política más flexible: permite tanto Passkeys como TOTP — el usuario elige durante el registro
ZITADEL también soporta TOTP estándar (Google Authenticator, cualquier app compatible con RFC 6238) y claves de seguridad físicas U2F/FIDO2 (YubiKey, etc.) para despliegues empresariales.
Solución de problemas: errores frecuentes de ZITADEL en Docker
masterkey must be 32 characters: usa openssl rand -hex 16 (32 caracteres hex = 16 bytes) para obtener una clave de longitud exacta.
connection refused en el puerto 8080 mientras el contenedor está en marcha: ZITADEL solo responde en :8080 cuando las migraciones están completas — start-from-init en una base vacía puede tardar de 30 a 90 segundos. Espera el log server is listening on [::]:8080.
Bucle de redirección HTTP/HTTPS: verifica que proxy_set_header X-Forwarded-Proto https esté en el bloque location / de nginx.
invalid_client durante el flujo OIDC: verifica que la URL de redirección declarada en la aplicación ZITADEL coincida exactamente con la que envía tu aplicación — ZITADEL es estricto en la coincidencia.
PostgreSQL rechaza la conexión: reinicia ZITADEL con docker compose restart zitadel. Usa restart: on-failure:5 para absorber los retrasos de inicio.
Pérdida de credenciales de administrador iniciales: elimina la base de datos (docker compose down -v) y reinicia start-from-init. En producción, crea inmediatamente una segunda cuenta de administrador.
Próximo paso: profundiza en tu stack SSO auto-alojado
ZITADEL en producción en un VPS es un excelente primer paso. Para ir más lejos:
- [Desplegar ZITADEL en VPS — guía avanzada](/deployer-zitadel-vps): certificados TLS automáticos con Let's Encrypt, backup de PostgreSQL a S3 y actualizaciones sin downtime.
- [Authentik vs Authelia: ¿qué SSO self-hosted para tu VPS?](/authentik-vs-authelia-sso-self-hosted): si tu caso de uso es menos orientado a multi-tenancy y más a proxy de autenticación.
- [Migrar de Keycloak a Authelia o ZITADEL](/keycloak-cves-semaine-38-migrer-authelia-zitadel-vps): las seis CVEs de la semana 38 analizadas y el camino de migración concreto desde un realm Keycloak existente.
- [Auto-alojar Authelia en VPS](/self-host-authelia-vps): si buscas una pasarela de autenticación ultra-ligera (menos de 30 MB) en lugar de un IdP completo.
Un VPS con 4 GB de RAM, acceso root e IPv4 dedicada cubre cómodamente ZITADEL en producción con margen para las aplicaciones que protege.
