El mejor CIAM autoalojado para creadores de SaaS B2B

Si has mirado los precios de algunas plataformas CIAM en SaaS, seguramente has notado lo caras que llegan a ser y lo más probable es que hayas considerado una opción autoalojada.

Este artículo trata sobre las cuatro plataformas CIAM autoalojadas que un equipo pequeño de SaaS B2B puede gestionar de verdad sin que se convierta en un segundo trabajo a tiempo completo: ZITADEL, FusionAuth, Logto y Ory Hydra. No todas tienen la misma forma, y la adecuada para ti depende menos de una lista de funciones y más del tipo de producto B2B que estás construyendo. Las ejecuté en paralelo en un mismo VPS durante una semana para preparar esta comparativa, y lo que sigue es la versión que le enviaría a un fundador que me escribe por privado sobre CIAM.

Una aclaración de entrada: esto va de CIAM como funcionalidad de producto, no de SSO interno para tu propio equipo.

La versión corta

Cuatro plataformas CIAM autoalojadas, una línea para cada una:

• ZITADEL si quieres multiinquilino y organizaciones B2B listos desde el primer momento.
• FusionAuth si quieres una interfaz de administración pulida y un historial de versiones largo y predecible.
• Logto si quieres la experiencia de desarrollo más limpia desde el primer día.
• Ory Hydra si trabajas a nivel de protocolo y quieres el motor OAuth 2.0, no una aplicación de login con opiniones propias.

En resumen: ZITADEL es la apuesta inicial más segura para un SaaS B2B típico, y el resto del artículo desglosa ese razonamiento.

Por qué el CIAM es una decisión distinta del SSO para empleados

Si el SSO de tu equipo interno se cae, el daño suele estar contenido. Tus ingenieros pueden perder el acceso a Grafana o a otra herramienta interna durante una hora. Si se cae el CIAM, tus clientes de pago no pueden iniciar sesión en el producto en absoluto. Eso cambia la pregunta de «¿qué herramienta de autenticación le resulta cómoda a nuestro equipo?» a «¿en qué sistema de autenticación podemos confiar como parte del propio producto?»

El CIAM, el tipo de infraestructura de identidad que necesita un SaaS B2B, también requiere primitivas que muchas herramientas de SSO para empleados no priorizan. Tu cliente no es un usuario único; es una organización (un tenant) con sus propios usuarios, roles, identidad visual y, posiblemente, su propia conexión SAML a un IdP corporativo. No solo estás autenticando personas; estás aislando a los usuarios de una empresa de los de otra dentro del mismo producto. Esta es la forma B2B a la que apuntan las cuatro herramientas de abajo, cada una a su manera. Keycloak ahora tiene Organizations de primera clase, así que descartarlo como algo solo para empleados sería una idea desfasada; explico su ausencia en las preguntas frecuentes.

El triángulo construir, comprar o autoalojar también se ve distinto aquí. Escribir OAuth desde cero es un error evitable. Estás lanzando un producto SaaS, no un proveedor de identidad. Comprar gestionado (Auth0, Clerk, WorkOS) es la decisión correcta cuando tu equipo no tiene nada de capacidad de operaciones y sí un presupuesto razonable. Nunca le diría a una startup de dos personas que autoaloje la autenticación el primer día. Autoalojar se vuelve racional cuando el precio por MAU del CIAM gestionado supera el coste de la infraestructura más el tiempo de ingeniería continuo, o cuando necesitas control directo del despliegue y del plano de datos. En los equipos con los que he trabajado, ese punto suele llegar entre «tenemos un producto de verdad» y «tenemos una función de customer success de verdad».

Si buscas SSO para tus propias aplicaciones y no para las de tus clientes, esa es una comparativa distinta a esta. Vamos con nuestras recomendaciones.

Las cuatro herramientas, una por una

Elegí estas cuatro porque tienen forma de CIAM lo bastante clara como para evaluarlas como infraestructura de producto, no solo como SSO interno. ZITADEL, FusionAuth, Logto y Ory ofrecen todas un camino real de autoalojamiento y suficiente tracción como para tomarlas en serio. Las opciones que son solo una biblioteca, las de SSO para empleados y las menos maduras se tratan mejor en las preguntas frecuentes.

ZITADEL

ZITADEL es una plataforma de identidad de origen suizo escrita en Go, con arquitectura basada en event sourcing y backend PostgreSQL. A 27 de julio de 2026, su última versión publicada en GitHub es la the 4.16 series, current as of July 2026. ZITADEL pasó de Apache 2.0 a AGPL-3.0 a partir de la v3; para un uso SaaS normal, el impacto práctico suele dar menos miedo del que parece, y explico los detalles en las preguntas frecuentes.

Lo que distingue a ZITADEL para el SaaS B2B: las organizaciones y el multiinquilino son primitivas de primera clase, no funciones que compones a partir de objetos genéricos. Creas una Organization, obtiene sus propios usuarios, políticas, identidad visual y ajustes de acceso, y puedes concederle proyectos para que sus administradores gestionen las asignaciones de roles de sus propios usuarios. No tienes que inventarte el concepto de «tenant» sobre usuarios genéricos. Empiezas con él.

La experiencia de desarrollo es API-first, con las API de recursos REST v2 actuales más acceso gRPC y REST a los servicios v1 heredados. Hay SDK oficiales y de la comunidad para las pilas de servidor habituales. La consola de administración es funcional, pero más sobria que la de FusionAuth.

Mi lectura: Si estás construyendo un SaaS B2B y sabes que vas a tener tenants, yo empezaría por ZITADEL. Entre las opciones autoalojadas, es la que está más explícitamente diseñada en torno al problema del login B2B.

FusionAuth

FusionAuth es una plataforma estadounidense de Inversoft, LLC (una LLC de Delaware que opera como FusionAuth) que lleva más tiempo que las otras tres, y se nota, para bien. La interfaz de administración se siente bastante más cuidada que las demás, la documentación es madura y la cadencia de versiones es constante en lugar de vertiginosa. Si alguna vez has heredado una integración de autenticación de cuatro años y le has dado las gracias en silencio al ingeniero anterior por elegir la opción aburrida, FusionAuth es la versión del CIAM que se gana ese agradecimiento.

Lo que hace tropezar a la gente es la licencia: FusionAuth Community es gratuito para autoalojar, pero el producto principal no es de código abierto. El producto se rige por la licencia propia de FusionAuth, y sus límites importan si planeas redistribuir, integrar, renombrar, revender o alojar FusionAuth para tus propios clientes. La versión Community autoalojada cubre el caso central del SaaS B2B; los planes de pago añaden funciones como SAML iniciado por el IdP, MFA avanzada y temas específicos por aplicación, mientras que SCIM, Tenant Manager y las políticas de MFA a nivel de aplicación quedan en Enterprise.

En cuanto a la forma B2B: FusionAuth modela tenants y aplicaciones, pero la abstracción es «autenticación en contenedores por tenant» más que «organizaciones B2B como objeto de dominio». Funciona (he lanzado productos sobre ello), pero el multiinquilino se siente más como una primitiva de aislamiento que como un modelo B2B de primera clase. Los SDK oficiales y bibliotecas cliente son amplios:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

Las bibliotecas de servidor son clientes de API ligeros. La consola de administración es comparativamente más fácil de entregar a una persona de operaciones sin perfil de ingeniería que las demás.

Mi lectura: Si tu equipo valora el acabado de la interfaz y un historial largo y predecible por encima de las primitivas nativas de B2B, entonces FusionAuth. Es la opción más «aburrida» de la lista, y eso es un cumplido.

Logto

Logto es el más reciente de los cuatro, desarrollado por Silverhand Inc. y con licencia MPL-2.0, y es el que más se nota que cuida su panel. La puesta en marcha del primer día es comparativamente rápida. Aprovisionas, pasas por el asistente y tienes un proveedor OIDC funcionando con una interfaz de login por defecto decente en unos quince minutos (lo cronometré la semana en que ejecuté los cuatro en paralelo). Sus guías de inicio rápido oficiales cubren frameworks y pilas de servidor modernos, así que si tu stack es «Next.js + Postgres + algo», te sentirás como en casa.

Su respuesta B2B se llama Logto Organizations. Cubre las primitivas B2B esenciales: pertenencia a una organización, roles con alcance de organización, invitaciones de miembros, aprovisionamiento just-in-time e integración de SSO empresarial. El modelo de organización es más nuevo que el de ZITADEL, así que yo probaría cualquier flujo SAML, SCIM o de federación poco habitual con tus clientes objetivo antes de comprometerte.

El compromiso es la madurez: Logto es la opción más reciente de la lista. La hoja de ruta avanza rápido, lo cual es genial cuando llega una función que necesitas e incómodo cuando llega un cambio incompatible. Si tu SaaS B2B está en el extremo sencillo del espectro multiinquilino (un conjunto pequeño de organizaciones y sin requisitos de federación exóticos), la experiencia de desarrollo de Logto hace más fácil el resto de la decisión.

Mi lectura: Si quieres el primer día más rápido y tus necesidades B2B siguen siendo relativamente simples, entonces Logto.

Ory Hydra (y la pila de Ory)

Ory Hydra es el servidor OAuth 2.0 / OpenID Connect del ecosistema Ory, con licencia Apache-2.0. La pila completa de Ory combina Hydra con Ory Kratos (identidad y gestión de usuarios, login de autoservicio, registro, MFA y recuperación de cuenta), Ory Keto (un servidor de autorización al estilo Zanzibar que actúa como punto de decisión de políticas) y Ory Oathkeeper (un proxy de identidad y acceso que autentica, autoriza y transforma las peticiones HTTP entrantes). Tú montas lo que necesitas. Todo está escrito en Go y las API son limpias.

El truco (y no es un defecto; para el equipo adecuado es una ventaja) es que Hydra es el motor, no la aplicación. Por diseño, Hydra se conecta a una aplicación de login y consentimiento independiente que tú proporcionas. Si quieres una pantalla de login lista para usar, esta no es la herramienta. Si estás construyendo algo donde el flujo de autenticación forma parte del producto (una plataforma para desarrolladores, un portal B2B a medida o un producto API-first con un onboarding propio), la ausencia de una interfaz impuesta es exactamente lo que buscas.

La historia B2B es componible en lugar de llave en mano. Puedes modelar el multiinquilino conectando esquemas de Kratos y relaciones de Keto a tu propia capa de organización, y funciona, pero el cableado lo haces tú. El coste es más fontanería; el beneficio es control sobre la experiencia. La documentación de Ory cubre la superficie del protocolo en profundidad, pero el modelo componible da por hecho que estás cómodo tomando decisiones a nivel de protocolo. Si «audience claim» o «PKCE» no te dicen nada, empieza por alguna de las otras tres.

Mi lectura: Si estás construyendo algo a nivel de protocolo (una pasarela de autenticación, flujos a medida, una plataforma para desarrolladores) y las aplicaciones estándar te resultan limitantes, Ory es la respuesta correcta. Para un SaaS B2B típico que quiere el login funcionando hoy, no lo es.

Cómo se comparan de un vistazo

Aquí tienes el resumen de las cuatro herramientas en una sola tabla, útil para una segunda pasada, no como sustituto de leer los perfiles de arriba.

¿Por cuál deberías empezar?

Cuatro escenarios breves que cubren a la mayoría de los equipos con los que hablaría de esto.

Estás construyendo un SaaS B2B y sabes que vas a tener tenants. Empieza por ZITADEL. Las primitivas de multiinquilino y organización están diseñadas exactamente para esto, la superficie de la API es completa y dedicarás menos tiempo a inventar el modelo de tenant que con cualquiera de las otras tres. El cambio a AGPL merece una revisión legal, pero un despliegue sin modificar e integrado por separado suele ser un caso de uso SaaS sin complicaciones.

Quieres la interfaz de administración pulida y una plataforma estable y predecible. FusionAuth. El plan Community cubre las necesidades básicas de muchos equipos; reserva tiempo para leer con calma la licencia y la matriz de funciones. Funciones como SAML iniciado por el IdP, MFA avanzada y temas específicos por aplicación requieren un plan de pago, mientras que SCIM, Tenant Manager y las políticas de MFA a nivel de aplicación quedan en Enterprise.

Tus necesidades B2B hoy son simples y quieres el primer día más rápido. Logto. Su experiencia de desarrollo el primer día fue la más rápida en mi prueba comparativa. Asume que estás apostando por un ecosistema más joven y revisa la elección si tus requisitos crecen hacia casos límite de federación que no has probado.

Estás construyendo algo donde los flujos de autenticación forman parte de la experiencia de producto. Ory Hydra (más Kratos, más Keto si necesitas permisos). Escribirás más código. Tendrás más control. Si ese intercambio no te resulta evidente, no eres el público de Ory. Elige alguna de las otras tres.

Si dos de estas descripciones te encajan, quédate por defecto con ZITADEL. Es el que mejor encaja de forma amplia y el que le daría a un equipo fundador pequeño sin hacer muchas preguntas adicionales.

Lo que te cuesta autoalojar (en operaciones)

Aquí viene la parte menos romántica del artículo.

Tu disciplina de copias de seguridad de PostgreSQL pasa a ser algo de lo que depende tu negocio. En estos despliegues, el estado de identidad que debes proteger puede incluir registros de usuario, credenciales con hash, secretos de MFA, credenciales de cliente OAuth y datos de sesión. Si pierdes ese estado, tus clientes pueden perder la capacidad de iniciar sesión. Configura copias automáticas antes de que se registre tu primer usuario real, prueba la restauración y pon la salud de las copias en el mismo canal de alertas que la disponibilidad de tu aplicación.

El ritmo de versiones cambia con el tiempo. ZITADEL v4.16.1 salió el 17 de julio de 2026 tras varias versiones en junio, y cada proyecto de aquí mantiene su propia cadencia y política de compatibilidad. Trata esa cadencia como un asunto de mantenimiento, no como un atajo para juzgar la calidad. Lee las notas de versión antes de ejecutar docker compose pull y programa una ventana de parches recurrente. Saltarse las actualizaciones del proveedor de identidad durante meses puede dejarte por detrás de las correcciones de seguridad y compatibilidad en tu primera auditoría real.

Las cosas mundanas que siempre te pillan por sorpresa: la renovación de certificados TLS (usa un proxy inverso con Let's Encrypt, automatiza las renovaciones y alerta ante fallos), la configuración del servidor de correo saliente para los correos de verificación y de restablecimiento de contraseña (SES, SendGrid, Postmark: elige uno y configura bien SPF/DKIM/DMARC o tus correos de restablecimiento acabarán en spam), la rotación de credenciales de cliente OAuth cuando se va un ingeniero, y limitar la tasa de los endpoints de login para que un ataque de credential stuffing no te clave la CPU.

Consejo: si usas un Postgres gestionado, no des por hecho que el usuario de base de datos de ejecución también puede crear el esquema. Crea de antemano la base de datos y el usuario, concede los privilegios de propiedad o de instalación necesarios, y ejecuta la primera configuración con las credenciales que espera cada herramienta. Si no, tu primera ejecución puede fallar con un error vago de permisos de base de datos y perderás una hora persiguiendo la pista equivocada.

Lo que la vía autoalojada te ahorra en dólares, te lo cobra en responsabilidad. Después de la instalación, presupuesta unas cuantas horas de ingeniería al mes para mantener sana la capa de identidad. Los equipos que asignan cero tiempo suelen descubrir el coste más tarde: durante una caída, en un caso límite raro de SAML o en su primera auditoría de seguridad.

Dónde desplegarlos

Un VPS Linux con Docker Compose puede ser un punto de partida sensato para evaluar y para cargas modestas, pero el dimensionado en producción y la alta disponibilidad dependen del tráfico, de los requisitos de seguridad y de tu tolerancia a las caídas. Así encajan las opciones de despliegue habituales:

• Alojamiento compartido no puede ejecutar ninguno. Necesitan almacenamiento persistente, puertos personalizados, acceso root para el runtime de contenedores y un backend de base de datos de verdad. PostgreSQL es la vía por defecto para la mayoría de esta lista, pero no es literalmente la única base de datos soportada por cada herramienta.
• Kubernetes puede ejecutar los cuatro, pero el camino oficial es desigual. ZITADEL, FusionAuth, y Ory publican charts de Helm oficiales, mientras que la documentación de autoalojamiento de Logto se centra en el despliegue con Docker y máquinas virtuales. Para un SaaS B2B pequeño que aún no ha llegado al punto en el que Kubernetes se paga solo en otras partes, suele ser sobreingeniería. Recurre a él cuando el resto de tu infraestructura ya esté ahí.
• El bare metal está bien si ya estás en bare metal. La mayoría de los equipos de SaaS B2B no lo están.

Para un piloto pequeño de un solo nodo, empezaría con 4 GB de RAM, 2 vCPU y 60 GB de almacenamiento NVMe, y luego haría pruebas de carga sobre el flujo de login real. Es una base de planificación, no un mínimo universal de producción. Las aplicaciones son relativamente ligeras, pero PostgreSQL necesita memoria y el hasheo de contraseñas necesita margen de CPU. La guía de producción de ZITADEL recomienda tener cuatro núcleos de CPU disponibles para los picos de hasheo de contraseñas.

Cuando el producto sea real y el tráfico sostenido, redimensiona a partir de mediciones. El almacenamiento rápido ayuda a la latencia de PostgreSQL, mientras que el margen de CPU importa durante el hasheo concurrente de contraseñas. Vigila la memoria, la E/S de base de datos, la latencia de login y la saturación de CPU en lugar de dar por hecho que un recurso importa más que el resto.

Ejecutar CIAM en producción significa que su disponibilidad pasa a ser problema tuyo. Nosotros usamos instancias VPS Linux de Cloudzy para este tipo de carga, con almacenamiento NVMe y un SLA de disponibilidad del 99,95 % en la plataforma subyacente. Cloudzy también ofrece un VPS de ZITADEL en un clic si prefieres saltarte el script de aprovisionamiento inicial; las otras tres proporcionan imágenes de contenedor oficiales para una instalación con Docker. Para una visión de nivel directivo de cómo encaja el control de acceso en el resto de tu postura de seguridad, la guía de buenas prácticas de IAM lo aborda desde el lado de las políticas.

Preguntas frecuentes

¿La licencia AGPL de ZITADEL afecta a mi SaaS?

Normalmente no para un despliegue sin modificar e integrado por separado, pero esto no es asesoramiento legal. Las obligaciones AGPL de ZITADEL se aplican a ZITADEL en sí. Si modificas ZITADEL y operas esa versión modificada como servicio de red, la licencia puede exigirte ofrecer el código fuente correspondiente bajo AGPL. La posición publicada de ZITADEL es que usar simplemente una instancia sin modificar como servicio de identidad de tu SaaS no obliga, por sí solo, a licenciar tu aplicación aparte bajo AGPL. Lee el anuncio de licencias de ZITADEL y busca asesoramiento legal si modificas, redistribuyes, integras u ofreces el software a terceros. También existe una licencia comercial.

¿Por qué Keycloak o Authentik no están en esta lista?

Keycloak y Authentik son excelentes herramientas de identidad autoalojadas (las uso), pero excluir Keycloak porque le faltan organizaciones B2B sería erróneo hoy: las versiones actuales de Keycloak incluyen Organizations, grupos de organización y controles de administración delegada. Lo dejé fuera porque esta comparativa se centra en cuatro opciones con un camino más directo para un SaaS B2B de equipo pequeño; Keycloak merece su propia evaluación cuando importan la operación de la JVM, la profundidad del ecosistema y la flexibilidad a nivel de realm. Authentik sigue encajando mejor con el SSO para empleados y aplicaciones internas que con el modelado de tenants nativo del producto.

¿Autoalojar sale más barato que Auth0?

Con pocos MAU, a menudo no. Tus horas de ingeniería cuestan más que la factura de Auth0 en el nivel de startup temprana. Autoalojar gana económicamente a la escala en la que el precio por MAU del CIAM gestionado supera el coste combinado de un VPS pequeño más las pocas horas de ingeniería al mes que le dedicarás. El punto de equilibrio exacto depende del coste por hora de tu equipo, de tu curva de crecimiento de MAU y de si tu producto necesita funciones empresariales que te empujan a los niveles más caros de Auth0. Trata el ahorro como real, pero no inmediato.

¿Cuál es el tamaño mínimo de VPS para un CIAM en producción?

Para un piloto pequeño de un solo nodo, 4 GB de RAM, 2 vCPU y almacenamiento NVMe son un punto de partida razonable, no una garantía de producción. Dimensiona a partir del tamaño de tu base de datos, la carga de logins concurrentes, el coste del hasheo de contraseñas y tu objetivo de disponibilidad. La propia guía de producción de ZITADEL recomienda tener cuatro núcleos de CPU disponibles para los picos de hasheo; otras herramientas y patrones de tráfico necesitan sus propias pruebas de carga.

¿Puedo migrar más tarde de un CIAM gestionado a autoalojado?

Sí, pero planifícalo como un proyecto de verdad. Los restablecimientos de contraseña no son inevitables: la exportabilidad y los formatos de hash soportados varían, y algunos destinos admiten la migración de usuarios en bloque o just-in-time mientras que otros obligan a restablecer. Los factores de MFA, los clientes OAuth, las sesiones activas, el estado de verificación de correo y los mapeos de tenants o roles requieren un tratamiento aparte. Si ya sospechas que autoalojarás más adelante, anota esas restricciones de exportación y migración antes de elegir el proveedor gestionado.