ZITADEL 4.17 frente a Keycloak: roles, OIDC y salida
ZITADEL 4.17.3 actualizó controles de identidad. Cómo compararlo con Keycloak para organizaciones, proyectos, roles, auditoría y salida técnica.
Una cuenta de administración cuesta poco hasta que mezcla clientes, roles y sesiones. ZITADEL 4.17.3, publicado el 4 de septiembre, corrigió cifrado de tokens de intención de identidad, validación de enlace y permisos por organización. Para una pyme con portal, intranet y proveedores, la pregunta útil es dónde conviene poner OIDC, roles, auditoría y salida técnica frente a Keycloak.
Qué cambia al separar identidades y permisos
La identidad dejó de ser una pantalla de usuario y contraseña. En un stack actual, el servicio de identidad emite tokens, separa organizaciones, define aplicaciones, entrega roles, registra eventos y permite retirar accesos. ZITADEL y Keycloak resuelven esa zona con filosofías distintas: ZITADEL empuja una estructura de organizaciones y proyectos muy explícita; Keycloak ofrece un ecosistema más extendido, con muchos despliegues y extensiones. La decisión técnica depende de quién opera, cuántos clientes comparten instancia y qué tan clara debe ser la salida. La identidad necesita cierre técnico. La encuesta 2025 de Stack Overflow marca que 45,52% de quienes respondieron usan de uno a cinco productos de software o plataformas en el trabajo, y 35,43% usan de seis a diez. Ese dato ayuda a poner escala: aun una pyme chica termina con CRM, correo, tablero, ERP, sitio, VPN y repositorios. Si cada herramienta conserva usuarios propios, la baja de una persona queda repartida en demasiados lugares. ZITADEL publicó la versión 4.17.3 con correcciones sobre tokens de intención de proveedores de identidad, autorización de enlace y chequeos de método de autenticación en la organización del usuario. Ese tipo de cambio muestra una idea central: la identidad se rompe en bordes pequeños, entre sesión, proveedor externo, organización y permiso. Un administrador que agrega un proveedor social o corporativo debe saber qué aplicación lo usa, qué rol entrega y qué bitácora queda si algo cambia.
Cómo funciona por dentro
El diseño mínimo tiene seis piezas. Primero, un proveedor de identidad que habla OIDC para aplicaciones web y API. Segundo, organizaciones o tenants que separan clientes, sedes o unidades de negocio. Tercero, proyectos y aplicaciones con redirect URI, scopes, roles y secretos. Cuarto, políticas de login, MFA y recuperación. Quinto, auditoría de eventos para altas, bajas, enlaces y cambios de rol. Sexto, backup y restauración de base, configuración y secretos operativos. La guía de producción de ZITADEL self-hosting muestra un despliegue con PostgreSQL y describe una arquitectura basada en eventos, dónde el estado puede reconstruirse desde el event store. La documentación de organizaciones y proyectos ordena una distinción práctica: una organización agrupa usuarios y políticas; un proyecto agrupa aplicaciones, servicios y roles. Esa separación resulta útil cuando una clínica, una bodega o un prestador logístico tiene portal de clientes, panel interno y acceso de proveedores. Keycloak sigue siendo una referencia fuerte para equipos que ya conocen realms, clients, groups y roles. ZITADEL conviene revisar cuando se busca una consola más centrada en organizaciones, auditoría de eventos y despliegue con PostgreSQL como pieza principal. La comparación debe bajar a pruebas: crear usuario, asignar rol, emitir token, revocar sesión, restaurar copia y retirar una aplicación completa.
Qué se instala o configura primero
En un proyecto UMSA, el primer entregable sería un mapa de identidad con tres aplicaciones reales: portal externo, panel interno y API. Cada una debe tener redirect URI, scopes, roles, responsable, entorno y secreto rotado. Después se crea una prueba de baja: se desactiva un usuario, se revocan sesiones y se verifica que ninguna aplicación acepte un token viejo. La pila inicial puede usar ZITADEL o Keycloak, PostgreSQL, proxy con TLS, backup diario, monitoreo y un tablero simple de eventos. Servidor, respaldo y monitoreo pueden ubicarse entre USD 45 y USD 120 mensuales, entre $68.850 y $183.600 al dólar oficial vendedor de $1530. La implementación inicial, con modelo de organizaciones, dos aplicaciones, roles, MFA, documentación de operación y restauración probada, puede ir de USD 1.600 a USD 3.600, entre $2.448.000 y $5.508.000. Ese rango deja afuera migración masiva de usuarios, hardening avanzado, auditoría externa y conectores propietarios. El primer entregable verificable cabe en una sesión de prueba: usuario creado, rol asignado, token emitido, permiso rechazado, sesión revocada y restauración ejecutada en una instancia secundaria. Para ver el caso cercano con Keycloak, sirve el antecedente de Keycloak 26.7 en pymes, grupos, sesiones y corte.
Dónde se rompe y cómo probarlo
El primer riesgo es el rol que existe en el token y falta en la aplicación. El síntoma aparece cuando el proveedor emite una claim correcta y el sistema destino la ignora. La prueba crea dos usuarios con roles distintos, entra al panel y exige que una acción administrativa quede bloqueada. El segundo riesgo es el proveedor externo sin cierre. El síntoma aparece cuando un login corporativo cambia y las cuentas locales quedan activas. La prueba vincula un proveedor, desactiva el usuario, revoca sesiones y registra el evento. El tercer riesgo es el backup parcial. La prueba restaura PostgreSQL y configuración en otra instancia, levanta el proveedor, emite un token de prueba y confirma que roles, aplicaciones y políticas regresan completos. El cuarto riesgo es la salida técnica olvidada. La prueba exporta organizaciones, usuarios, aplicaciones y roles en un formato documentado, conserva hashes o referencias de credenciales según permita la herramienta y deja un procedimiento para apagar el servicio sin perder historial. La decisión no pasa por elegir una marca de login. Pasa por definir quién puede entrar, qué token recibe, quién aprueba cambios y cómo vuelve el servicio después de una falla.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.