El universo self-hosted tiene un problema tan viejo como inevitable: cuantos más servicios levantas, más credenciales acabas gestionando. Hoy es un panel de Grafana, mañana un Nextcloud, pasado un wiki interno, y al final terminas con una colección de logins que no escala ni para ti… ni para tu equipo.
En ese contexto aparece VoidAuth, un proyecto open source que se presenta como proveedor de autenticación y gestión de usuarios pensado para colocarse “delante” de tus aplicaciones autoalojadas, centralizando el inicio de sesión y el control de acceso. Su idea es directa: un portal de login único, soporte OpenID Connect (OIDC), modo ForwardAuth como proxy, y funciones modernas como passkeys y MFA, con un despliegue sencillo (por ejemplo, vía Docker Compose) y sin convertir tu homelab en una consultoría de IAM.
Qué propone VoidAuth (en la práctica)
VoidAuth se define como un “SSO para tu universo autoalojado”. A nivel funcional, el proyecto destaca por:
- Proveedor OIDC para que aplicaciones compatibles deleguen el login y reciban tokens de forma estándar.
- ForwardAuth / proxy para proteger servicios que no soportan OIDC nativo, haciendo de “capa” de autenticación delante del reverse proxy.
- Gestión de usuarios y grupos, con invitaciones y auto-registro (según configuración).
- Passkeys y MFA, incluyendo la posibilidad de cuentas “solo passkey”.
- Reset de contraseña por email y plantillas personalizables (branding y mensajes).
- Cifrado en reposo con base de datos Postgres o SQLite.
Todo ello con una promesa atractiva para perfiles técnicos: levantarlo rápido, integrarlo con tu proxy (Caddy/Traefik/Nginx, etc.) y empezar a proteger servicios sin reconfigurar uno por uno cada login.
También hay un punto importante que el propio proyecto reconoce: no ha sido auditado y se apoya en paquetes de terceros para parte de su funcionalidad. Eso no invalida su utilidad, pero sí obliga a tratarlo como lo que es: software joven que conviene desplegar con criterio (segmentación de red, backups, mínimos privilegios y monitorización).
Comparativa: VoidAuth frente a “otros métodos” habituales
En el mundo real, la elección no suele ser “VoidAuth sí o no”, sino “¿qué me compensa para mi caso?”. Estas son las rutas más comunes y cómo encaja VoidAuth:
1) El método “rápido”: Basic Auth, listas IP allowlist y contraseñas por app
Es el punto de partida típico. Funciona… hasta que:
- tienes varios usuarios,
- necesitas revocar accesos sin romper todo,
- quieres MFA o passkeys,
- o te piden trazabilidad y consistencia.
VoidAuth gana aquí por centralizar identidades y por su enfoque de “poner un guardia” delante de múltiples apps con una experiencia de login coherente.
2) “Directorio + LDAP” (FreeIPA / LDAP / AD)
LDAP/AD es muy potente, pero no siempre es amable si lo que buscas es solo SSO para herramientas web autoalojadas. Además, muchas apps modernas hablan mejor OIDC que LDAP.
VoidAuth puede resultar más directo si tu objetivo es SSO web y control de acceso sin montar (o mantener) un directorio completo.
3) Authelia (ligero, muy usado en homelab)
Authelia suele gustar por ser minimalista, integrarse bien como “capa” delante del proxy y resolver el 80% de casos de acceso web. Authelia también puede actuar como proveedor OIDC y se usa mucho en Kubernetes/homelab.
Dónde compite VoidAuth: en el pack de producto: portal/login + gestión de usuarios/grupos + passkeys + registro/invitaciones, buscando una experiencia más “todo en uno” para admins y usuarios.
4) Keycloak (el estándar enterprise, pero más pesado)
Keycloak es una bestia del IAM: maduro, extensible, con mucha integración OIDC/SAML y un ecosistema enorme (a costa de complejidad).
Dónde puede encajar VoidAuth: cuando quieres algo más ligero y centrado en proteger apps autoalojadas sin entrar en una implantación “corporativa” completa.
5) Authentik (muy completo, a medio camino entre homelab y empresa)
Authentik suele destacar por su enfoque visual de flujos, su capacidad como IdP y su integración con muchas apps. Pero también implica curva de aprendizaje y “peso” de plataforma.
VoidAuth puede tener ventaja si priorizas simplicidad operativa y un set de funciones claro para “SSO del día a día”.
6) SSO gestionado (Okta, Entra ID, Google, etc.)
La alternativa “de pago” tiene un argumento imbatible: outsourcing del problema, SLA, auditorías, soporte. El coste es doble: dinero y dependencia.
Aquí la ventaja de VoidAuth es obvia para el mundo self-hosted: open source + autoalojable, con control total de datos, despliegue y políticas (a cambio de que el operador seas tú).
La ventaja diferencial: open source que se puede autoalojar “de verdad”
En la práctica, la etiqueta open source solo importa si habilita algo concreto. En VoidAuth, esa ventaja se traduce en:
- Soberanía de despliegue: lo ejecutas donde quieras (tu servidor, tu CPD, tu cloud privado).
- Coste predecible: sin tarifas por usuario/MAU que crecen a medida que tu stack crece.
- Capacidad de inspección y adaptación: puedes revisar, auditar por terceros si lo necesitas, o extenderlo para tu caso.
- Evitar el “vendor lock-in” en tu autenticación, que es uno de los puntos más sensibles de cualquier arquitectura.
Y además, en un momento donde el interés por agentes locales, herramientas autoalojadas y privacidad está subiendo, un SSO propio es una pieza que encaja cada vez mejor en el puzle.
Lo que conviene vigilar antes de adoptarlo
Para una adopción responsable (y sin sorpresas), hay tres preguntas que merecen atención:
- Madurez y auditoría: si tu entorno es crítico o regulado, te interesa un roadmap claro, revisiones de seguridad y/o auditorías externas.
- Integración real con tus apps: OIDC y ForwardAuth cubren mucho, pero siempre hay excepciones.
- Operación y backups: al centralizar el login, conviertes este componente en infraestructura “core”. Alta disponibilidad, copias y restauración ya no son opcionales.
FAQs
¿VoidAuth sirve si mis aplicaciones no soportan OIDC?
Sí, la idea del modo ForwardAuth es justamente proteger aplicaciones sin OIDC nativo colocando la autenticación delante del servicio, a través del reverse proxy.
¿Qué ventaja aportan las passkeys en un entorno self-hosted?
Reducen dependencia de contraseñas reutilizadas, mejoran la resistencia al phishing y simplifican el acceso para usuarios no técnicos (si el flujo está bien implementado).
¿Cuándo es mejor usar Keycloak o Authentik en lugar de VoidAuth?
Cuando necesitas un IAM más completo (SAML, flujos complejos, federación avanzada, políticas corporativas, integraciones masivas) y aceptas más complejidad operativa.
¿El hecho de que sea open source lo hace automáticamente más seguro?
No. Open source facilita auditoría e inspección, pero la seguridad real depende de diseño, mantenimiento, actualizaciones, configuración y (idealmente) revisiones externas.