--- title: "VoidAuth: el “portero” open source para unificar el acceso a tus apps autoalojadas (y por qué puede tener sentido frente a Keycloak, Authelia o el SSO de pago)" description: "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 wik..." url: https://revistacloud.com/voidauth-portero-open-source-unificar-acceso-apps-autoalojadas/ date: 2025-12-19 modified: 2025-12-19 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2025/12/single-sign-on.jpg categories: ["Guías y recursos"] tags: ["autenticación multifactor", "open source", "SSO", "voidauth"] type: post lang: es --- # VoidAuth: el “portero” open source para unificar el acceso a tus apps autoalojadas (y por qué puede tener sentido frente a Keycloak, Authelia o el SSO de pago) 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](https://github.com/voidauth/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](https://github.com/voidauth/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: 1. **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. 2. **Integración real con tus apps:** OIDC y ForwardAuth cubren mucho, pero siempre hay excepciones. 3. **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. -