Cómo configurar Authelia con Nginx Proxy Manager paso a paso

Cuando alojas tus propias aplicaciones, es habitual terminar con varios paneles, gestores de archivos y servicios internos accesibles mediante diferentes subdominios. Nginx Proxy Manager facilita la publicación de esas aplicaciones y la gestión de certificados HTTPS, pero no puede corregir por sí solo una autenticación débil o inexistente en el servicio de destino.

Authelia añade una barrera delante de esas aplicaciones. Antes de permitir el acceso, puede solicitar usuario, contraseña y un segundo factor de autenticación. La combinación de Authelia con Nginx Proxy Manager permite centralizar el acceso sin tener que modificar cada aplicación protegida.

Este sistema resulta especialmente útil para mejorar la seguridad de aplicaciones web autoalojadas, siempre que también se cierren los accesos directos a sus puertos internos.

Cómo funciona Authelia con Nginx Proxy Manager

En esta integración, Nginx Proxy Manager sigue siendo el único componente que recibe las conexiones públicas. Cuando alguien intenta abrir una aplicación protegida, Nginx realiza una petición interna de autorización a Authelia.

Si el usuario ya dispone de una sesión válida y cumple la política correspondiente, Nginx entrega la aplicación. Si no está autenticado, lo redirige al portal de Authelia. Después de introducir sus credenciales y, cuando corresponda, el código TOTP, regresa automáticamente al servicio solicitado.

El recorrido queda así:

1. El visitante abre https://app.example.com.
2. Nginx Proxy Manager consulta a Authelia.
3. Authelia comprueba la sesión y la política de acceso.
4. El usuario se autentica en https://auth.example.com.
5. Nginx permite el acceso a la aplicación interna.

Este mecanismo se denomina autenticación reenviada o Forward Auth. No debe confundirse con OpenID Connect: en este caso, la aplicación final no necesita integrar directamente un proveedor de identidad.

Qué necesitas antes de comenzar

Para completar la configuración necesitarás:

• Una instalación funcional de Nginx Proxy Manager.
• Docker y Docker Compose instalados en el servidor.
• Un dominio y dos subdominios, como auth.example.com y app.example.com.
• Registros DNS que apunten ambos subdominios hacia el proxy.
• Un certificado HTTPS válido para cada dominio.
• Una red Docker compartida entre Nginx Proxy Manager, Authelia y las aplicaciones protegidas.
• Una aplicación interna que no sea accesible directamente desde Internet.

El uso de HTTPS no es opcional. Authelia necesita cookies seguras y todas las aplicaciones protegidas mediante Forward Auth deben utilizar HTTPS o WSS en su dirección pública.

Cómo crear la red compartida y cerrar los puertos internos

Crea una red externa que puedan compartir los distintos archivos de Docker Compose:

docker network create proxy

Después, conecta Nginx Proxy Manager, Authelia y las aplicaciones protegidas a esa red:

networks:
  proxy:
    external: true

Una definición básica del contenedor de Authelia puede quedar así:

services:
  authelia:
    image: authelia/authelia:latest
    container_name: authelia
    restart: unless-stopped
    volumes:
      - ./config:/config
    expose:
      - "9091"
    networks:
      - proxy
    environment:
      TZ: Europe/Madrid

networks:
  proxy:
    external: true

La directiva expose documenta el puerto utilizado dentro de la red, pero no es lo que impide el acceso exterior. La medida realmente importante es no incluir una sección ports para Authelia ni para las aplicaciones protegidas.

Solo Nginx Proxy Manager debería publicar los puertos 80 y 443. Su puerto de administración, normalmente el 81, debería limitarse a la red local, una VPN o direcciones autorizadas mediante el cortafuegos.

En producción también conviene sustituir latest por una versión concreta que hayas probado, evitando actualizaciones inesperadas.

Cómo configurar Authelia

Dentro de la carpeta montada como /config, crea el archivo configuration.yml. Para una instalación individual puedes utilizar SQLite y el proveedor de sesiones en memoria:

identity_validation:
  reset_password:
    jwt_secret: 'CAMBIA_ESTE_SECRETO_JWT'

authentication_backend:
  file:
    path: '/config/users_database.yml'

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'app.example.com'
      policy: 'two_factor'

session:
  secret: 'CAMBIA_ESTE_SECRETO_DE_SESION'
  cookies:
    - domain: 'example.com'
      authelia_url: 'https://auth.example.com'
      default_redirection_url: 'https://app.example.com'

storage:
  encryption_key: 'CAMBIA_ESTA_CLAVE_DE_CIFRADO'
  local:
    path: '/config/db.sqlite3'

notifier:
  filesystem:
    filename: '/config/notification.txt'

Cambia example.com por tu dominio real. En la configuración actual de Authelia, las cookies se declaran dentro de session.cookies, y authelia_url debe contener la dirección HTTPS completa del portal.

Genera valores aleatorios independientes para el secreto JWT, la sesión y el cifrado del almacenamiento:

docker run --rm authelia/authelia:latest authelia crypto rand --length 64 --charset alphanumeric

Ejecuta el comando tres veces y no reutilices el mismo valor. Para entornos sensibles, es preferible guardar estos datos mediante Docker Secrets o archivos de secretos con permisos restringidos.

El notificador de archivos resulta útil durante las pruebas porque guarda los enlaces de registro y recuperación en notification.txt. Para producción debes configurar SMTP. Authelia solamente admite un proveedor de notificaciones activo a la vez.

Redis tampoco es obligatorio en este despliegue. El almacenamiento de sesiones en memoria es suficiente para una única instancia. Si vas a ejecutar varias réplicas de Authelia, necesitarás un proveedor compartido como Redis y una base de datos externa en lugar de SQLite.

Cómo crear usuarios y contraseñas seguras

Authelia no guarda las contraseñas en texto plano. Para generar un hash Argon2 de forma interactiva, ejecuta:

docker run --rm -it authelia/authelia:latest authelia crypto hash generate argon2

Introduce la contraseña cuando el comando la solicite y copia el resultado completo, comenzando por $argon2id$. Después, crea users_database.yml:

users:
  usuario:
    disabled: false
    displayname: 'Usuario principal'
    password: '$argon2id$PEGA_AQUI_EL_HASH_COMPLETO'
    email: '[email protected]'
    groups:
      - 'admins'

El valor almacenado es un hash de la contraseña, no una cadena cifrada reversible. Si habilitas el restablecimiento de contraseñas, Authelia deberá tener permiso de escritura sobre este archivo.

Los grupos permiten definir políticas más precisas. Por ejemplo, puedes exigir dos factores únicamente a los administradores o impedir que determinados usuarios accedan a una aplicación concreta.

Cómo definir las políticas de acceso

Authelia evalúa las reglas en el orden en el que aparecen y aplica la primera coincidencia. Por eso, las reglas específicas deben colocarse antes que las generales:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'panel.example.com'
      policy: 'two_factor'
      subject:
        - 'group:admins'

    - domain: 'wiki.example.com'
      policy: 'one_factor'

    - domain: '*.example.com'
      policy: 'two_factor'

Las políticas principales son:

• deny: bloquea completamente la petición.
• bypass: permite el acceso sin autenticación.
• one_factor: exige usuario y contraseña.
• two_factor: exige además un segundo factor.

No es necesario crear una regla bypass para auth.example.com si el Proxy Host del portal no incluye la comprobación de autorización. Proteger el portal con su propio auth_request puede provocar un bucle de redirección infinito.

Cómo publicar el portal de Authelia en Nginx Proxy Manager

La integración oficial utiliza varios fragmentos de configuración:

• proxy.conf
• authelia-location.conf
• authelia-authrequest.conf
• websocket.conf, cuando la aplicación utilice WebSockets

Descarga las versiones actuales de estos snippets y monta su carpeta dentro del contenedor de Nginx Proxy Manager:

volumes:
  - ./data:/data
  - ./letsencrypt:/etc/letsencrypt
  - ./snippets:/snippets:ro

Los snippets actuales utilizan el endpoint /api/authz/auth-request. No reutilices configuraciones antiguas basadas en /api/verify, ya que corresponden a una integración heredada.

Después, crea el Proxy Host del portal con estos valores:

• Domain Names: auth.example.com
• Scheme: http
• Forward Hostname/IP: authelia
• Forward Port: 9091
• SSL Certificate: un certificado válido
• Force SSL: activado

En la pestaña Advanced, añade:

location / {
    include /snippets/proxy.conf;
    proxy_pass $forward_scheme://$server:$port;
}

Este Proxy Host publica el portal, pero no lo protege con su propia petición de autenticación.

Cómo proteger una aplicación con Authelia

Crea otro Proxy Host para la aplicación. Como ejemplo:

• Domain Names: app.example.com
• Scheme: http
• Forward Hostname/IP: nombre del contenedor de la aplicación
• Forward Port: puerto interno del servicio
• Force SSL: activado

En la pestaña Advanced, utiliza:

include /snippets/authelia-location.conf;

location / {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass $forward_scheme://$server:$port;
}

La configuración incluida consulta a Authelia antes de entregar cada petición. Si la aplicación necesita WebSockets, añade también:

include /snippets/websocket.conf;

Cuando se define manualmente un bloque location en la pestaña Advanced, algunos interruptores de la pestaña Details dejan de aplicarse. Por eso, activar solamente Websockets Support desde la interfaz puede no ser suficiente.

Este esquema también puede utilizarse para proteger Open WebUI con contraseña y segundo factor, siempre que el contenedor sea accesible desde la red compartida.

Cómo tratar las APIs y ubicaciones personalizadas

Las rutas creadas desde la pestaña Custom Locations de Nginx Proxy Manager no heredan automáticamente la protección de Authelia. Una ubicación desprotegida podría permitir saltarse las políticas configuradas.

Si necesitas una ruta personalizada, declárala en Advanced e incluye expresamente la comprobación:

location /custom {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass http://servicio:8080;
}

Las aplicaciones móviles y algunas APIs tampoco pueden seguir una redirección hacia el portal de autenticación. Sin embargo, no debes aplicar bypass a toda la API por comodidad.

Excluye solamente una ruta concreta cuando esta disponga de su propio mecanismo de autenticación. Por ejemplo:

- domain: 'app.example.com'
  policy: 'bypass'
  resources:
    - '^/api/health$'

Comprueba que la expresión regular no incluya accidentalmente otros endpoints sensibles.

Cómo activar el segundo factor

Con la política two_factor activa, inicia sesión y registra un dispositivo TOTP. Durante las pruebas, Authelia escribirá el enlace de registro en:

./config/notification.txt

Abre el enlace, escanea el código QR con una aplicación compatible y confirma el código temporal. En producción debes sustituir el notificador de archivos por SMTP para que los enlaces lleguen al usuario mediante correo electrónico.

Si los códigos TOTP son rechazados, comprueba la hora del servidor:

timedatectl status

El elemento determinante es que el reloj esté sincronizado mediante NTP. La variable TZ ayuda a presentar fechas correctamente, pero no corrige una hora desincronizada.

Cómo comprobar que la protección funciona

Después de iniciar Authelia, revisa sus registros:

docker compose logs --tail=200 authelia

Comprueba también que Nginx Proxy Manager pueda resolver el nombre del contenedor:

docker exec nginx-proxy-manager getent hosts authelia

Sustituye nginx-proxy-manager por el nombre real de tu contenedor. Después:

1. Cierra cualquier sesión abierta en Authelia.
2. Abre directamente la aplicación protegida.
3. Comprueba que te redirige a auth.example.com.
4. Completa el nivel de autenticación esperado.
5. Confirma que regresas a la aplicación original.
6. Prueba que el puerto interno no responde desde otro equipo.

Si utilizas políticas basadas en direcciones IP, asegúrate de que Nginx sustituya las cabeceras X-Forwarded-For enviadas por el cliente. Confiar ciegamente en esas cabeceras permitiría falsear la IP de origen y saltarse determinadas reglas de red.

Una vez desplegado, puedes monitorizar la aplicación con Uptime Kuma, teniendo en cuenta que una comprobación externa debería recibir la redirección hacia Authelia en lugar del contenido privado.

Errores frecuentes al conectar Authelia con Nginx Proxy Manager

Error 502 Bad Gateway

Nginx Proxy Manager no puede alcanzar Authelia o la aplicación. Comprueba que los contenedores pertenezcan a la misma red Docker y que el nombre y el puerto internos sean correctos.

Bucle de redirección hacia el portal

Revisa que el Proxy Host de auth.example.com no incluya authelia-authrequest.conf. Comprueba también el dominio de la cookie, la dirección authelia_url y el uso consistente de HTTPS.

Authelia muestra Access Denied

La petición no coincide con ninguna regla permitida o ha sido interceptada por una regla anterior. Recuerda que las políticas se evalúan secuencialmente y se aplica la primera coincidencia.

La aplicación sigue siendo accesible sin iniciar sesión

Comprueba que el contenedor no tenga un puerto publicado directamente. Revisa también las ubicaciones personalizadas de Nginx Proxy Manager, porque pueden quedar fuera de la verificación de Authelia.

La interfaz carga, pero algunas funciones no responden

Probablemente la aplicación utiliza WebSockets. Incluye websocket.conf dentro del bloque location y revisa las conexiones desde las herramientas de desarrollo del navegador.

No llega el enlace para registrar el segundo factor

Si utilizas el notificador de archivos, revisa notification.txt y sus permisos. Si utilizas SMTP, comprueba el servidor, el puerto, el cifrado y las credenciales.

Los códigos TOTP aparecen siempre como incorrectos

Verifica la hora del host y del contenedor. Un desfase de pocos minutos puede invalidar todos los códigos aunque la zona horaria esté bien configurada.

Los cambios de configuración no se aplican

Revisa primero los registros para detectar errores de sintaxis y reinicia Authelia:

docker compose restart authelia

Valida nuevamente el flujo después de modificar las reglas, actualizar Nginx Proxy Manager o cambiar cualquiera de los snippets.

Proteger aplicaciones con Authelia y Nginx Proxy Manager permite añadir una capa centralizada de autenticación y segundo factor sin modificar los servicios originales. La seguridad depende, sin embargo, de cerrar los accesos directos, utilizar HTTPS, mantener los snippets actualizados y comprobar cuidadosamente las reglas y ubicaciones personalizadas. Con esos elementos correctamente configurados, el proxy se convierte en el único punto de entrada y Authelia decide quién puede atravesarlo.