Alojar Authelia en un VPS: MFA y SSO para todo tu stack

Sin una pasarela centralizada, cada servicio gestiona su propio login: Grafana tiene su base de usuarios, Nextcloud la suya, Portainer la suya. El resultado: contraseñas distintas en todos lados, sin MFA coherente y una superficie de ataque multiplicada. Authelia resuelve esto interceptando el flujo HTTP: tu reverse proxy (Nginx, Traefik, Caddy) le envía cada solicitud antes de reenviarla, y Authelia decide — según la identidad, el grupo, la ruta solicitada y el nivel de MFA requerido — si la solicitud debe pasar. La aplicación protegida solo ve una solicitud autenticada con cabeceras de identidad inyectadas (Remote-User, Remote-Groups).

Antes de desplegar Authelia, verifica que tu entorno esté listo. Necesitas un VPS con Linux con Docker y Docker Compose instalados, un reverse proxy existente (Traefik v2/v3 o Nginx), un nombre de dominio con certificado TLS válido (Let's Encrypt recomendado), y una instancia Redis accesible por Authelia para almacenar sesiones (obligatorio en producción). Para el almacenamiento de usuarios, puedes empezar con un archivo YAML local o conectar un servidor LDAP como LLDAP. Authelia también requiere una clave JWT, una clave de cifrado de sesión y un secreto OIDC si activas ese modo: genéralos con openssl rand -hex 32.

La sección access_control es el corazón de la lógica de Authelia. Desde v4.37, las políticas han sido rediseñadas. Acceso público sin auth: {domain: 'status.midominio.com', policy: bypass}. Acceso MFA fuerte restringido a admins: {domain: 'portainer.midominio.com', subject: 'group:admins', policy: two_factor}. Ruta de API sin auth (webhooks): {domain: 'n8n.midominio.com', resources: ['^/webhook/.*'], policy: bypass}. El resto de N8N con MFA simple: {domain: 'n8n.midominio.com', policy: one_factor}. default_policy: deny garantiza que todo lo no listado queda bloqueado. El orden de las reglas importa: se aplica la primera que coincida.

Authelia soporta tres métodos de segundo factor, cada uno con sus ventajas.

TOTP (Contraseña de un solo uso basada en tiempo) es el método más universal: el usuario escanea un código QR con una app como Aegis (Android), Raivo (iOS) o Bitwarden Authenticator. Un código de 6 dígitos cambia cada 30 segundos. Simple de desplegar, compatible con todos los dispositivos, pero vulnerable al phishing si el código se intercepta.

WebAuthn/passkey es el método más robusto, soportado nativamente por Authelia desde v4.36. El usuario registra una llave física (YubiKey, Nitrokey) o un autenticador de plataforma (Touch ID en macOS, Windows Hello, Face ID en iOS). La criptografía de clave pública hace el phishing imposible: la clave privada nunca sale del dispositivo. Authelia implementa la especificación WebAuthn Level 2 completa, incluyendo passkeys sincronizadas vía iCloud Keychain o Google Password Manager.

Duo delega el segundo factor al servicio cloud Duo Security: push móvil, SMS o llamada telefónica. Práctico para equipos que ya usan Duo, pero introduce dependencia en un servicio externo.

Para la mayoría de stacks auto-alojados, la combinación recomendada es TOTP como método base y WebAuthn como método preferido para usuarios con YubiKey o dispositivo Apple/Windows reciente.

El backend archivo (users_database.yml) sirve para un usuario o familia pequeña, pero se vuelve difícil de gestionar con más de 5-10 usuarios. LLDAP (Light LDAP) es una implementación LDAP ligera escrita en Rust, con una interfaz web simple, que se integra perfectamente con Authelia.

Despliega LLDAP añadiendo su servicio a tu docker-compose.yml con las variables LLDAP_JWT_SECRET y LLDAP_LDAP_BASE_DN (ej: dc=midominio,dc=com). Crea tus grupos en la interfaz LLDAP (admins, users, devops…), luego modifica configuration.yml para cambiar del backend file al backend ldap.

Atención al breaking change de v4.35: el campo se llamaba authentification_backend (con error tipográfico) antes de v4.35 y fue corregido a authentication_backend. Verifica tu configuración si migras desde una versión anterior.

Authelia sigue un versionado semántico estricto y documenta sus breaking changes por versión. Los cambios notables:

v4.34: el proveedor OIDC pasa a producción. Si lo usabas en modo experimental, verifica los cambios de nombre de opciones.

v4.35: corrección authentification_backend → authentication_backend — cualquier configuración con el nombre antiguo impide el arranque con un error de validación.

v4.37: rediseño de políticas access_control — la sintaxis de las reglas se volvió más explícita. Consulta el changelog oficial antes de actualizar desde v4.36 o anterior.

v4.38.x (versión actual): estabilización, sin breaking changes mayores desde v4.37.

Procedimiento de actualización recomendado: (1) lee el changelog desde tu versión actual; (2) haz backup de /opt/authelia/config/ y /opt/authelia/data/; (3) prueba la configuración nueva con docker run --rm -v /opt/authelia/config:/config authelia/authelia:4.38.x authelia validate-config antes de reiniciar; (4) actualiza el tag en docker-compose.yml y reinicia.

Authelia expone sus métricas Prometheus en /metrics (puerto configurable, por defecto 9959). Actívalas en configuration.yml con telemetry.metrics.enabled: true y telemetry.metrics.address: 'tcp://0.0.0.0:9959'. No expongas este puerto públicamente: límitalo a tu stack de monitorización interno (Prometheus/Grafana).

Métricas clave a vigilar: authelia_authn_requests_total (intentos de autenticación, etiquetados por éxito/fallo), authelia_authn_duration_seconds (latencia), y las métricas de Redis para la salud de las sesiones. Para los logs, Authelia soporta formato JSON estructurado (log.format: json), ideal para ingestión en Loki o un SIEM. Usa log.level: info en producción (evita debug, que registra headers completos). Los logs de autenticación incluyen la IP origen, nombre de usuario, servicio objetivo y resultado — muy útiles para detectar ataques de fuerza bruta antes de que tengan éxito.

Bucle de redirección infinito. El usuario rebota entre el servicio y el portal Authelia. Causa más frecuente: session.domain no coincide con el dominio del servicio. Si el servicio está en app.misite.com y session.domain es otro dominio, la cookie de sesión nunca se envía. Verifica también que el middleware forwardAuth está bien aplicado y que default_redirection_url apunta a una URL válida.

Cookie domain mismatch. session.domain debe ser el dominio padre común (misite.com), no un subdominio. Verifica con DevTools (Application > Cookies) que authelia_session tiene el dominio correcto.

Redis inalcanzable. Authelia arranca pero las sesiones no persisten. Verifica que el contenedor Redis está en la misma red Docker, que host en configuration.yml coincide con el nombre del servicio (no localhost), y que Redis no está protegido por contraseña no configurada en Authelia.

Configuración inválida al arrancar. Desde v4.35, el esquema de configuración se valida estrictamente. Usa authelia validate-config antes de cualquier reinicio. Los errores más comunes: authentification_backend (typo antiguo), indentación YAML incorrecta, o client_secret OIDC que debe hashearse con Argon2id desde v4.37.

MFA no solicitado a pesar de two_factor en las reglas. Verifica que el usuario ha registrado un segundo factor en su perfil. Sin dispositivo MFA registrado, Authelia puede aplicar un fallback a one_factor según default_2fa_method.