Por qué una pasarela de autenticación en el reverse proxy
Cada herramienta autoalojada que añade a su VPS es una nueva superficie de ataque. Algunas disponen de una autenticación sólida (Gitea, Nextcloud); otras están pensadas para redes de confianza (Prometheus, Dockge, paneles internos) y no ofrecen ninguna autenticación. Añadir una verificación de usuario y contraseña a cada aplicación por separado lleva tiempo, genera incoherencias y, aun así, le deja con decenas de bases de credenciales distintas que gestionar.
Authelia resuelve el problema en el nivel de la infraestructura. La configura una sola vez — con reglas del tipo «toda persona que acceda a *.internal.su-dominio.com debe validar una autenticación de dos factores» — y su reverse proxy aplica esas reglas a cada petición, antes de que llegue a la aplicación. Las aplicaciones en sí no necesitan ninguna modificación.
Lo que le aporta Authelia autoalojado
- MFA para cualquier aplicación: TOTP (Google Authenticator, Ente Auth, Aegis), WebAuthn/Passkeys (Touch ID, Face ID, YubiKey) y Duo push — configurado una vez, aplicado en todas partes.
- Proveedor OpenID Connect (OIDC): configure Authelia como proveedor de identidad para Gitea, Nextcloud, Mattermost y cualquier aplicación compatible con OIDC. Un solo inicio de sesión, todas sus aplicaciones.
- Control de acceso preciso: defina políticas por dominio, subdominio, ruta de URL, red IP o grupo de usuarios — permitir, denegar, un factor o dos factores.
- Independiente del reverse proxy: integración de copiar y pegar con Nginx, Caddy, Traefik, HAProxy y Envoy mediante una sola directiva
forward_auth. - Menos de 30 MB de RAM en reposo — se añade a cualquier VPS existente sin afectar a las cargas de trabajo en curso.
- Backend de usuarios basado en archivo o en LDAP — empiece de forma sencilla y escale más adelante.
Requisitos previos
Un VPS con al menos 1 vCPU y 512 MB de RAM (1 GB recomendado) con Ubuntu 22.04 o Debian 12, con Docker y Docker Compose v2 instalados. Es obligatorio un nombre de dominio que apunte al VPS: las cookies de sesión y los callbacks OIDC de Authelia deben ir asociados a un FQDN en regla, y el HTTPS mediante Let's Encrypt es imprescindible. Si su VPS ya ejecuta Caddy o Nginx como reverse proxy, Authelia se integra en él.
Desplegar Authelia con Docker Compose
Redactar el archivo Compose
Cree
/opt/authelia/compose.yaml. La stack consta de dos servicios:authelia/authelia:4.39.20yredis:7-alpine. Authelia guarda los datos de sesión en Redis y el estado de la aplicación (base de datos SQLite, registro de notificaciones) en un volumen Docker con nombre, montado en/data. Dos montajes bind desde./aportan el archivo de configuración y la base de usuarios: los genera el job de provisioning de ServOrbit.Crear configuration.yml
Authelia lee su configuración desde
/config/configuration.yml(montado en bind desde el host). La configuración mínima define la dirección del servidor (tcp://:9091), el backend de autenticación por archivo (/config/users.yml), el dominio y el secreto de sesión, la ruta de almacenamiento SQLite, el host Redis para las sesiones y las reglas de control de acceso. Empiece condefault_policy: denyy añada reglasone_factorpara sus dominios.Crear la base de usuarios
El backend de archivo de Authelia lee un archivo YAML con los nombres de usuario, las contraseñas con hash bcrypt, los correos electrónicos y los grupos. Genere un hash para su contraseña de administrador con:
docker run --rm authelia/authelia:4.39.20 authelia crypto hash generate bcrypt. Pegue la salida enusers.yml. En ServOrbit, el job de provisioning escribe este archivo automáticamente, con una contraseña generada que se muestra en la salida del job.Iniciar la stack y comprobar
Ejecute
docker compose up -den/opt/authelia. Compruebe que ambos contenedores están sanos condocker compose ps. Authelia expone un endpoint de salud enGET /api/health:curl -s http://localhost:9091/api/healthdebe devolver{"status":"OK"}. El portal de inicio de sesión queda entonces disponible enhttps://auth.su-dominio.comuna vez configurado su reverse proxy.Añadir la directiva forward_auth a su proxy
Para Caddy, añada
forward_auth authelia:9091a los bloques de sitio que quiera proteger, referenciando el nombre de servicio del contenedor Authelia si ambos están en la misma red Docker. Para Nginx, añadaauth_request /authelia;y el bloque location correspondiente. La documentación de Authelia ofrece fragmentos de copiar y pegar para cada proxy importante. Recargue la configuración de su proxy: cada aplicación protegida exigirá a partir de ahora un inicio de sesión a través de Authelia.Registrar su dispositivo MFA
Inicie sesión en el portal de Authelia en
https://auth.su-dominio.comcon sus credenciales de administrador. Se le pedirá registrar un segundo factor. Abra su aplicación TOTP (Google Authenticator, Ente Auth o Aegis), escanee el código QR y confirme. Para las passkeys (WebAuthn), haga clic en «Security Key or Passkey» y siga la indicación de su navegador: Face ID, Touch ID y las YubiKey funcionan todas. Los inicios de sesión siguientes exigirán su contraseña y el factor registrado.Conectarse por primera vez
Abra la dirección de su portal: Authelia pide un usuario y una contraseña. Introduzca «admin» y la contraseña que se le ha comunicado (disponible en la sección Aplicaciones de su área de cliente) y registre de inmediato su aplicación de autenticación (TOTP) o su clave de acceso: es el segundo factor que protegerá después todo lo que coloque detrás de este portal.
Usar Authelia como proveedor OIDC para un SSO real
Una vez Authelia en marcha, puede registrar sus demás aplicaciones autoalojadas como clientes OIDC. En configuration.yml, añada un bloque identity_providers.oidc que liste, para cada aplicación, el client ID, el secreto y las redirect URIs. Configure después la aplicación (Gitea, Nextcloud, Grafana…) para que use Authelia como proveedor OIDC. Los usuarios se autentican una sola vez en auth.su-dominio.com y son redirigidos de forma silenciosa a cada aplicación conectada por OIDC: se acabaron las peticiones de inicio de sesión separadas, una sola sesión para toda su stack.
Reglas de control de acceso
La sección de control de acceso de Authelia es el lugar donde define quién puede acceder a qué. Las reglas se evalúan de arriba abajo; gana la primera coincidencia. Una configuración de producción mínima puede dejar pasar sus aplicaciones expuestas públicamente, exigir un factor para las herramientas internas habituales e imponer dos factores para todo lo sensible (paneles de administración, gestores de secretos, bases de datos). Use el campo groups de users.yml para distinguir a los administradores de los usuarios corrientes y aplicar políticas más estrictas a los miembros del grupo admin.
