Tienes ocho contenedores Docker corriendo en un VPS. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, una página de estado y una app interna que escribiste tú mismo. Cada uno tiene su propio inicio de sesión. Copias y pegas contraseñas desde tu gestor cada mañana, y has empezado a preguntarte si el inicio de sesión único compensa su coste operativo.
Normalmente sí. La pregunta es qué proveedor de identidad ejecutar.
Keycloak es la opción por defecto más conocida, pero el mejor encaje depende de cómo sea tu stack, de cuántos usuarios gestionas y de si integras software que ya ejecutas o si construyes la autenticación dentro de tus propias aplicaciones.
Esta comparativa de SSO autoalojado analiza Authentik, ZITADEL, Keycloak y Authelia a través de las decisiones que importan una vez desplegados: soporte de protocolos, gestión de usuarios, flujo de trabajo para desarrolladores, requisitos de recursos y qué pasa cuando tu proveedor de identidad se cae.
Por qué importa el SSO autoalojado
En cuanto varias aplicaciones dependen de las mismas personas y grupos, los inicios de sesión separados dejan de ser cómodos. Un proveedor de identidad autoalojado te da un único lugar para gestionar cuentas, MFA, pertenencia a grupos y políticas de acceso, en vez de configurar esos controles por separado en cada aplicación.
La contrapartida es igual de importante: el IdP se convierte en infraestructura de la que dependen otras aplicaciones. Los nuevos inicios de sesión y las renovaciones de tokens pueden fallar cuando no está disponible, así que las copias de seguridad, el acceso de recuperación, las actualizaciones y la disponibilidad importan más aquí que en una app autoalojada corriente.
TL;DR
Elige Authentik si quieres la mejor opción por defecto
Para un homelab, un stack de herramientas internas o un equipo pequeño que conecta aplicaciones existentes mediante OIDC o SAML, Authentik es la opción por defecto más sólida. Su flujo de administración es más accesible que el de Keycloak, admite varios métodos de integración y su configuración oficial de Docker Compose parte de 2 núcleos de CPU y 2 GB de RAM.
Elige ZITADEL si estás construyendo aplicaciones
Elige ZITADEL cuando la autenticación forma parte del producto que estás construyendo. Su modelo de organizaciones, sus API, la multitenencia, OIDC, SAML, las passkeys, la MFA y el soporte de proveedores de identidad LDAP tienen más sentido para equipos de aplicaciones SaaS y B2B que para un homelab típico.
Elige Keycloak si necesitas funciones de identidad empresarial
Elige Keycloak cuando necesites una federación más profunda con LDAP o Active Directory, varios realms, políticas de autorización granulares o un entorno ya construido alrededor de Keycloak. Su documentación recomienda un límite de memoria de 2 GB para contenedores Keycloak pequeños listos para producción; un VPS todo en uno que además ejecute PostgreSQL necesita margen adicional.
Alternativa: elige Authelia si sobre todo necesitas un muro de inicio de sesión
Elige Authelia cuando tu problema principal sea proteger aplicaciones en la capa del proxy inverso en lugar de ejecutar una plataforma de identidad completa. También puede actuar como proveedor OpenID Connect, pero la autenticación en el proxy inverso sigue siendo su centro de gravedad.
Qué comprobar antes de elegir una herramienta de SSO
Antes de comparar funciones, contrasta cada herramienta con las aplicaciones, protocolos y fuentes de identidad que ya necesitas soportar.
¿Cuántas apps necesitan SSO?
Empieza por las aplicaciones, no por el proveedor de identidad. Un stack con seis aplicaciones que ya soportan OIDC o SAML es un problema distinto a un stack de viejas herramientas internas que no saben nada de ninguno de los dos protocolos. El primer caso apunta a un IdP completo. El segundo puede necesitar autenticación en la capa del proxy inverso.
¿Tus apps soportan OIDC o SAML?
OIDC es la elección habitual para aplicaciones web modernas. SAML sigue importando en software empresarial e integraciones antiguas. LDAP puede importar cuando la aplicación espera un directorio en lugar de un flujo SSO web. Comprueba qué acepta realmente cada aplicación antes de elegir el IdP que se colocará en medio.
¿Gestionas usuarios o integras el inicio de sesión en una app?
Si la mayor parte de tu trabajo ocurrirá en una interfaz de administración mientras conectas aplicaciones existentes, Authentik es el punto de partida natural. Si la autenticación forma parte de un producto que estás construyendo y esperas aprovisionar organizaciones, usuarios y permisos mediante código, ZITADEL está mucho más cerca de ese flujo de trabajo.
¿Necesitas LDAP, Active Directory o políticas avanzadas?
Authentik, ZITADEL y Keycloak pueden conectarse de alguna forma a fuentes de identidad respaldadas por LDAP, así que LDAP por sí solo ya no decide la comparación. Keycloak se vuelve más interesante cuando la federación de directorios se combina con varios realms, mappers detallados, requisitos de sincronización o políticas de autorización a nivel de recurso.
Authentik vs ZITADEL vs Keycloak vs Authelia
Las cuatro herramientas se solapan en el SSO, pero abordan la identidad desde direcciones distintas: integración de aplicaciones, identidad de producto, IAM empresarial y acceso mediante proxy inverso.
Authentik
Authentik ejecuta su despliegue básico como un servidor, un worker y una base de datos PostgreSQL. Redis ya no forma parte del stack: Authentik eliminó por completo la dependencia en la versión 2025.10. La documentación actual de Docker Compose exige un host con al menos 2 núcleos de CPU y 2 GB de RAM.
El rasgo definitorio es la interfaz de administración. El motor de flujos de Authentik, el aprovisionamiento de aplicaciones y las políticas por grupos son más accesibles que el modelo de configuración más amplio de Keycloak. Si alguna vez configuraste una aplicación OIDC en Keycloak y luego pasaste tiempo averiguando por qué faltaban los claims de tu token, la diferencia se nota rápido.
Soporta SAML, OAuth2/OIDC, LDAP y RADIUS. Es la opción por defecto correcta para un homelab o un equipo de ingeniería pequeño que ejecuta un stack de apps autoalojadas.
ZITADEL
ZITADEL está escrito principalmente en Go, con licencia AGPL-3.0, y se encuentra en la línea de versiones v4.x. El despliegue incluye una API en Go, una interfaz de inicio de sesión en Next.js y PostgreSQL, y los requisitos actuales soportan PostgreSQL 14 a 18. La documentación oficial de Docker Compose exige un host con al menos 2 GB de RAM.
El rasgo definitorio es la API. ZITADEL expone una superficie de identidad completa sobre gRPC y REST y está construido desde el principio sobre un modelo multitenant. Si estás construyendo un producto SaaS y quieres que la capa de inicio de sesión sea programable, automatizable y multitenant por defecto, ZITADEL está más cerca de lo que buscas que las alternativas.
Soporta OIDC, SAML, passkeys, MFA, proveedores de identidad LDAP y una interfaz SCIM v2 actualmente marcada como Preview. Su modelo de organizaciones y su flujo de trabajo API-first lo hacen más adecuado para equipos de producto que para un simple homelab.
Keycloak
Keycloak es una plataforma de gestión de identidades y accesos en Java que se ejecuta sobre Quarkus. Tiene una superficie de configuración mayor que las demás opciones de aquí, sobre todo cuando entran en juego Realms, Clients, Roles, federación de usuarios y Authorization Services.
Su documentación oficial de contenedores recomienda un límite de memoria de 2 GB para despliegues pequeños listos para producción. Esa cifra cubre el contenedor de Keycloak en sí; si PostgreSQL comparte el mismo VPS, dale más margen al host.
La razón para aceptar esa complejidad es concreta. Keycloak puede federar directorios LDAP y Active Directory, registrar eventos de usuarios y administradores, y aplicar autorización granular con políticas RBAC, ABAC, basadas en usuario, basadas en contexto y de otros tipos. Si necesitas esos controles, la configuración adicional tiene un propósito.
Authelia
Authelia es el más pequeño de los cuatro: licencia Apache 2.0, un único binario en Go, actualmente en v4.39.x. La arquitectura es distinta a la de los otros tres: Authelia se sitúa delante de un proxy inverso (nginx, Traefik, Caddy, HAProxy) y decide si las peticiones pueden llegar al backend.
Authelia también incluye un proveedor OpenID Connect. Su documentación todavía describe la implementación de OIDC como beta abierta, pero el proveedor está certificado por OpenID para los perfiles Basic OP, Implicit OP, Hybrid OP, Form Post OP y Config OP. Su conjunto de funciones OIDC es más reducido que lo que ofrecen Authentik o Keycloak para la gestión de identidades, y por eso Authelia sigue teniendo más sentido cuando la autenticación en el proxy inverso es la tarea principal.
Volveremos a Authelia en su propia sección. La versión corta: el centro de gravedad de Authelia es el control de acceso en el proxy inverso, no la gestión completa de identidades.
Comparativa de funciones
La tabla siguiente limita la comparación a las diferencias que afectan al despliegue y a la administración diaria.
| Característica | Authentik | ZITADEL | Keycloak | Authelia |
|---|---|---|---|---|
| Protocolos soportados | OAuth2/OIDC, SAML, LDAP, RADIUS, autenticación por proxy | OAuth2/OIDC, SAML, proveedor de identidad LDAP, SCIM v2 en Preview | OAuth2/OIDC, SAML, federación LDAP y Active Directory | Proveedor OIDC más autenticación en el proxy inverso |
| Gestión de usuarios y grupos | Usuarios, grupos, políticas, flujos, vinculaciones de aplicaciones | Usuarios, organizaciones, proyectos, roles, concesiones | Usuarios, grupos, realms, roles de cliente, roles de realm, federación | Gestión de usuarios ligera, normalmente respaldada por archivos o LDAP |
| Experiencia para desarrolladores | API disponible, pero la interfaz de administración es su principal fortaleza | API-first, modelo sólido de organizaciones y multitenencia | API REST maduras con un modelo IAM más grande que aprender | Principalmente basado en configuración |
| Funciones empresariales | Políticas, federación, outposts, controles de acceso a aplicaciones | Organizaciones, proyectos, passkeys, federación, SCIM v2 en Preview | Federación profunda, varios realms, eventos, Authorization Services | Reglas de control de acceso y fuerte integración con el proxy inverso |
| Facilidad de configuración | Punto de partida más sencillo para la mayoría de stacks de aplicaciones autoalojadas | Ideal cuando el equipo piensa en API e identidad de producto | Más conceptos y configuración, pero controles más profundos | El más simple cuando la tarea es sobre todo autenticación en el proxy inverso |
| Recursos recomendados | Mínimo oficial de Compose: 2 núcleos de CPU y 2 GB de RAM | Mínimo oficial de Compose para el host: 2 GB de RAM | 2 GB de memoria de contenedor recomendados para despliegues de producción pequeños | Sin mínimo oficial de RAM directamente comparable |
¿Qué herramienta encaja con qué stack?
El mejor encaje cambia según quién opera el IdP y cómo se integran las aplicaciones con él.
Mejor opción para un homelab
Authentik es la opción por defecto para un homelab donde la mayoría de las aplicaciones ya soportan OIDC o SAML. Te da un proveedor de identidad completo sin obligarte a adoptar el modelo IAM más amplio de Keycloak. Si la mayor parte del stack necesita una pantalla de inicio de sesión en el proxy inverso en lugar de SSO nativo, Authelia puede ser la opción más sencilla.
Mejor opción para el stack de una pequeña empresa
Authentik encaja en la mayoría de los stacks pequeños de aplicaciones internas, sobre todo cuando el objetivo es una única capa de identidad para herramientas como Grafana, Gitea, Nextcloud y Vaultwarden. Keycloak se vuelve más atractivo cuando un directorio existente, varios realms o políticas de autorización más profundas forman parte del requisito.
Mejor opción para desarrolladores y productos SaaS
ZITADEL es la mejor opción cuando la autenticación forma parte del producto que estás construyendo. Su modelo de organizaciones, la multitenencia, las API y la superficie de automatización tienen más sentido cuando usuarios y tenants deben aprovisionarse desde el código de la aplicación en lugar de principalmente desde un panel de administración.
Mejor opción para equipos empresariales o con fuertes exigencias de cumplimiento
Keycloak tiene sentido cuando la lista de requisitos incluye federación de directorios compleja, varios realms, políticas de autorización detalladas y un equipo capaz de operar la complejidad IAM adicional. Autoalojar Keycloak no hace que un entorno cumpla la normativa por sí solo; las copias de seguridad, la disponibilidad, el registro, las revisiones de acceso y los controles de cambios siguen siendo responsabilidad de tu equipo.
Mejor opción para apps sin SSO nativo
Authelia es la opción más clara cuando la autenticación tiene que ocurrir antes de que las peticiones lleguen a la aplicación. Funciona especialmente bien con proxies inversos que protegen herramientas internas antiguas, paneles y servicios que no soportan OIDC ni SAML por sí mismos.
La parte difícil de autoalojar el SSO
Una vez que el SSO es obligatorio, un error de configuración o una recuperación fallida puede afectar a varias aplicaciones a la vez.
Instalación y configuración
Poner en marcha los contenedores es solo el primer paso. DNS, TLS, URI de redirección, claims de tokens, mapeos de grupos, entrega de correo y acceso de recuperación son los puntos donde un despliegue de SSO empieza a convertirse en infraestructura en lugar de una app Docker más.
Recursos del servidor
El IdP es solo una parte del presupuesto de recursos. PostgreSQL, proxies inversos, workers, hash de contraseñas, registros y sincronización de directorios pueden competir por CPU y memoria cuando comparten un VPS.
Gestión de la base de datos y las copias de seguridad
Authentik, ZITADEL y los despliegues normales de Keycloak en producción dependen de una base de datos. Haz copia de esa base fuera del servidor, documenta cómo restaurarla y prueba la restauración. Un trabajo de copia exitoso no es lo mismo que un procedimiento de recuperación que funciona.
Riesgos de bloqueo y recuperación
Una URI de redirección incorrecta, un secreto de cliente caducado, una conexión de directorio rota o una política demasiado estricta pueden dejar fuera a los administradores junto con todos los demás. Mantén una vía de recuperación que no dependa del flujo de autenticación que intentas reparar.
Mantener el IdP disponible
Una caída del IdP no termina necesariamente de inmediato todas las sesiones de aplicación existentes. Las sesiones en curso pueden continuar hasta que caduquen sus propios tokens o cookies, pero los nuevos inicios de sesión y las renovaciones de tokens pueden fallar. Prueba ese modo de fallo antes de hacer el SSO obligatorio en todo el stack.
Cuándo no deberías autoalojar el SSO
Autoalojar deja de ser un buen trato cuando tu equipo no puede restaurar y operar la capa de identidad con la fiabilidad que exigen tus aplicaciones.
Cuándo la identidad gestionada es más segura
La identidad gestionada merece la pena cuando el coste de operar el IdP es mayor que el control que ganas autoalojándolo. Servicios como Auth0, Clerk, WorkOS y Microsoft Entra ID trasladan al proveedor gran parte de la disponibilidad de la plataforma, los parches y el mantenimiento de la infraestructura.
Sigues siendo responsable de la configuración de las aplicaciones, los permisos y la planificación de la recuperación, pero ya no de mantener en línea la propia plataforma de identidad.
Cuándo tu equipo no puede asumir una caída
Si nadie en el equipo puede restaurar el IdP, reparar PostgreSQL, sustituir un secreto caducado o diagnosticar una conexión de federación fallida durante una incidencia, autoalojar la identidad puede ser el compromiso operativo equivocado.
El fallo va más allá de una única aplicación no disponible. Los nuevos inicios de sesión y las renovaciones de tokens de varias aplicaciones pueden fallar al mismo tiempo.
Cuándo las exigencias de cumplimiento son demasiado altas
La identidad autoalojada puede usarse en entornos regulados, pero ejecutar el software tú mismo no produce automáticamente los controles ni las evidencias que espera un auditor. Tu equipo sigue siendo responsable del registro, las revisiones de acceso, las copias de seguridad, la gestión de cambios, la disponibilidad, la respuesta a incidentes y toda la documentación que exija el marco aplicable.
El SSO autoalojado no es un símbolo de estatus. Si tu equipo no puede operar la capa de identidad con seguridad, pagar por identidad gestionada puede ser la mejor decisión de ingeniería.
Dónde ayuda Cloudzy
Cloudzy cambia la capa de despliegue; no elimina el trabajo de configuración de identidad ni de operación descrito arriba.
El problema del despliegue manual de SSO
Un despliegue manual de SSO implica preparar el servidor, instalar la aplicación y la base de datos, configurar el proxy inverso, ajustar DNS y TLS, y solo entonces empezar la configuración de la identidad en sí. Nada de eso sustituye el trabajo de OIDC, SAML, directorio o políticas que viene después.
Despliegue de SSO en un clic en Cloudzy
Cloudzy tiene despliegues en un clic para Authentik y Keycloak. La app de Authentik en un clic está en el marketplace de Cloudzy. La app de Keycloak en un clic también está en el marketplace de Cloudzy. ZITADEL no está hoy en el marketplace, así que despliégalo con su configuración de Docker Compose en un VPS estándar. La instalación en un clic pone en marcha la aplicación base, mientras que la configuración de identidad, el DNS, las copias de seguridad, las actualizaciones, las políticas y las pruebas de recuperación siguen bajo tu control.
Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.
Ver planes LinuxCuándo usar un VPS separado para tu IdP
Alojar el IdP junto a tus aplicaciones es razonable en un homelab donde una caída es aceptable. Para un stack crítico para el negocio, separar el proveedor de identidad elimina un dominio de fallo compartido evidente: reiniciar, agotar o comprometer el servidor de aplicaciones ya no significa tumbar la capa de identidad con él.
Un VPS separado no es lo mismo que alta disponibilidad, pero le da al IdP su propio presupuesto de recursos, su propio calendario de mantenimiento y su propio límite de recuperación.
Recomendaciones de dimensionamiento del VPS
Dimensiona todo el stack, no solo el proceso del IdP, sobre todo cuando PostgreSQL y un proxy inverso comparten el mismo VPS.
Requisitos de VPS para Authentik
La documentación oficial de Docker Compose de Authentik exige un host con al menos 2 núcleos de CPU y 2 GB de RAM. Ese es el punto de partida correcto para un despliegue pequeño. Dale más margen al servidor cuando PostgreSQL, outposts adicionales, la sincronización de directorios o un tráfico de inicio de sesión mayor compartan el mismo host.
Requisitos de VPS para ZITADEL
El despliegue oficial de Docker Compose de ZITADEL exige al menos 2 GB de RAM para el host. Dimensiona un VPS todo en uno para ZITADEL, su interfaz de inicio de sesión, PostgreSQL y el proxy inverso en conjunto, en lugar de tratar el servicio Go de forma aislada.
Requisitos de VPS para Keycloak
La documentación de contenedores de Keycloak recomienda un límite de memoria de 2 GB para despliegues pequeños de Keycloak listos para producción. Esa cifra se aplica al contenedor de Keycloak en sí, no a un VPS entero que además ejecuta PostgreSQL.
Si Keycloak y PostgreSQL comparten un VPS, 4 GB de RAM del sistema son un punto de partida sensato. Trátalo como una guía práctica para el host y no como el mínimo oficial de Keycloak.
Requisitos de VPS para Authelia
Authelia no publica un mínimo de servidor de 1 GB o 2 GB directamente comparable. Dimensiona el host para Authelia junto con el proxy inverso, el backend de almacenamiento, el directorio de usuarios y cualquier otro servicio que comparta la máquina.
Authelia suele tener una huella de despliegue menor que ejecutar un IdP completo junto a PostgreSQL, pero los requisitos reales de VPS dependen del resto del stack.
Ejemplo de configuración: Authentik con Vaultwarden
Vaultwarden añadió soporte nativo de SSO con OpenID Connect en la versión 1.35.0, en diciembre de 2025. Authentik es un ejemplo útil porque la integración expone las piezas de OIDC que también encontrarás con otras aplicaciones: URI de redirección, credenciales de cliente, scopes, URL de emisor y acceso de recuperación.
Configuración básica de Authentik
En Authentik:
- Crea un mapeo de scope de correo personalizado para Vaultwarden. Vaultwarden exige que el scope email devuelva email_verified: true o ningún valor email_verified en absoluto, mientras que el scope de correo por defecto de Authentik devuelve actualmente false.
- Crea un par de aplicación y proveedor OAuth2/OpenID Connect.
- Añade https://vault.example.com/identity/connect/oidc-signin como URI de redirección estricta de tipo Authorization.
- Selecciona cualquier clave de firma disponible.
- Anota el Client ID, el Client Secret y el slug de la aplicación.
- Configura la validez del token de acceso en más de cinco minutos.
- Añade el mapeo offline_access de Authentik a los scopes seleccionados.
- Sustituye el mapeo de correo por defecto por el mapeo personalizado de correo verificado del paso 1.
Configuración básica de OIDC en Vaultwarden
Usa:
DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=trueSustituye los dominios de ejemplo, el slug de la aplicación, el ID de cliente y el secreto de cliente por los valores de tu propio despliegue y reinicia Vaultwarden.
Qué probar antes de imponer el SSO
Deja SSO_ONLY en false mientras pruebas el inicio de sesión, el cierre de sesión, la renovación de tokens, la coincidencia de cuentas y la recuperación. Prueba también qué ocurre cuando Authentik no está disponible temporalmente.
Una vez que tanto el SSO como la recuperación funcionan como se espera, puedes decidir si exigir SSO en cada inicio de sesión tiene sentido para tu despliegue.
Los mismos conceptos de OIDC se aplican a otras aplicaciones autoalojadas, pero las URI de redirección, los scopes, los claims y las licencias difieren. Consulta la documentación de SSO de cada aplicación en lugar de copiar directamente la configuración de Vaultwarden.
Cuándo Authelia es mejor que un IdP completo
Authelia resulta más atractivo cuando la aplicación no necesita entender en absoluto al proveedor de identidad.
Autenticación en el proxy inverso
Authelia está diseñado principalmente para proteger aplicaciones en la capa del proxy inverso. Tú defines reglas de control de acceso y Authelia decide si una petición debe llegar al backend antes de que la propia aplicación gestione la autenticación.
Proteger apps sin OIDC
Esto es útil para herramientas internas antiguas, paneles y servicios que no soportan OIDC ni SAML. En lugar de modificar cada aplicación, puedes poner la autenticación delante de ella, en el proxy inverso.
Authelia también puede actuar como proveedor OIDC, pero la autenticación en el proxy inverso sigue siendo su principal fortaleza.
Usar Authelia junto con Authentik
Puedes usar Authentik para las aplicaciones que soportan OIDC o SAML y Authelia para las que necesitan autenticación en el proxy inverso.
No necesitas necesariamente ambos. Authentik también soporta la protección de aplicaciones mediante proxy, así que usar Authelia a su lado solo tiene sentido cuando el flujo de proxy inverso de Authelia resuelve de forma más limpia una parte concreta de tu stack.
Preguntas frecuentes
¿Es Authentik mejor que Keycloak?
Para la mayoría de homelabs y stacks pequeños de aplicaciones autoalojadas, Authentik es más accesible. Su flujo de administración se centra en aplicaciones, proveedores, grupos y políticas sin exponer tanta complejidad IAM de golpe.
Keycloak tiene más sentido cuando necesitas específicamente su federación más profunda, su modelo de realms o sus Authorization Services. Authentik es la opción por defecto más sólida para un SSO autoalojado más sencillo; Keycloak encaja en entornos que necesitan esos controles adicionales.
¿Es ZITADEL mejor que Keycloak?
ZITADEL encaja mejor cuando estás construyendo un producto y quieres identidad gestionada por API, organizaciones y multitenencia. Keycloak encaja mejor cuando necesitas su modelo de autorización más profundo, sus amplios controles de federación o un entorno ya construido alrededor de Keycloak.
¿Cuál es la diferencia entre Authentik y Authelia?
Authentik es un proveedor de identidad completo construido en torno a usuarios, grupos, aplicaciones, proveedores, flujos y políticas. Las aplicaciones pueden integrarse con él directamente mediante protocolos como OIDC y SAML.
Authelia se centra en la autenticación y el control de acceso en el proxy inverso. También incluye un proveedor OIDC, pero la protección en el proxy inverso sigue siendo su caso de uso principal.
Elige Authentik cuando las aplicaciones se integran directamente con un IdP. Elige Authelia cuando la autenticación tiene que ocurrir sobre todo antes de que el tráfico llegue a la aplicación.
¿Puedo ejecutar Authentik en un VPS de 1 GB?
No como punto de partida soportado. La documentación actual de Docker Compose de Authentik exige al menos 2 núcleos de CPU y 2 GB de RAM. El despliegue básico actual usa el servidor de Authentik, el worker y PostgreSQL; Redis se eliminó por completo en Authentik 2025.10.
Usa 2 GB como punto de partida mínimo para una instalación pequeña y añade margen cuando otros servicios compartan la máquina.
¿Vaultwarden soporta SSO con OIDC?
Sí. Vaultwarden añadió soporte de SSO con OpenID Connect en la versión 1.35.0, en diciembre de 2025. Requiere un proveedor OIDC externo como Authentik, Keycloak o ZITADEL.
La configuración exacta depende del proveedor. Con las versiones actuales de Authentik, la integración documentada incluye un mapeo personalizado de scope de correo verificado, offline_access, credenciales de cliente y la URL de emisor de la aplicación de Authentik.
¿Debo ejecutar mi IdP en el mismo VPS que mis apps?
Para un homelab donde una caída es aceptable, alojarlos juntos puede ser razonable. Para aplicaciones críticas para el negocio, un VPS separado le da al proveedor de identidad su propio presupuesto de recursos y saca al servidor de aplicaciones del dominio de fallo compartido.
Eso no crea alta disponibilidad por sí solo, pero un reinicio del servidor de aplicaciones, un problema de recursos o un compromiso ya no tumban automáticamente el IdP con él.
¿Qué SSO autoalojado es el más fácil de usar?
Authentik es el punto de partida más fácil para la mayoría de las personas que conectan aplicaciones autoalojadas existentes. Su interfaz de administración hace que aplicaciones, proveedores, grupos y políticas sean más accesibles que el modelo más amplio de realms y autorización de Keycloak.
Authelia puede ser más sencillo cuando solo necesitas autenticación en el proxy inverso. ZITADEL tiene más sentido cuando la persona que configura la identidad es un desarrollador que trabaja principalmente a través de API.
Debate
Comentarios
Inicia sesión para unirte al debate.