Cómo proteger una aplicación web con Authelia sin modificarla

Muchas aplicaciones autoalojadas incluyen sistemas de acceso demasiado básicos o directamente carecen de autenticación. Publicarlas mediante un dominio y añadirles HTTPS mejora la conexión, pero no evita que cualquier persona llegue hasta su interfaz e intente iniciar sesión.

Authelia permite colocar una barrera de autenticación delante de una aplicación sin modificar su código. Cuando alguien intenta abrirla, el proxy inverso consulta primero a Authelia. Solamente después de validar el usuario, la contraseña y, si corresponde, el segundo factor, la petición continúa hacia el servicio.

Esta guía parte de que Authelia y el proxy inverso ya están funcionando. Si todavía necesitas preparar esa infraestructura, primero debes configurar Authelia con Nginx Proxy Manager y comprobar que ambos contenedores pueden comunicarse.

Qué significa proteger una aplicación con Authelia

Authelia no se instala dentro de la aplicación ni modifica su base de datos. La protección se aplica en el proxy inverso mediante un sistema denominado autenticación reenviada o Forward Auth.

El flujo funciona de la siguiente manera:

1. El usuario abre el dominio de la aplicación.
2. El proxy envía una consulta interna a Authelia.
3. Authelia comprueba la sesión y las políticas de acceso.
4. Si falta autenticación, redirige al usuario hacia su portal.
5. Una vez autorizado, el proxy entrega la aplicación solicitada.

Esto permite añadir contraseña y 2FA a paneles internos, gestores de archivos, herramientas de monitorización o aplicaciones que no ofrecen una protección suficiente.

Sin embargo, Authelia solamente controla el acceso previo. Si la aplicación también tiene su propio formulario de login, es posible que el usuario tenga que autenticarse dos veces. Para iniciar sesión automáticamente dentro de la aplicación, esta debe admitir OpenID Connect, SAML o autenticación mediante encabezados de confianza.

Qué necesitas antes de proteger la aplicación

Antes de comenzar, comprueba que dispones de:

• Una instancia funcional de Authelia.
• Un proxy inverso compatible correctamente integrado con Authelia.
• Un dominio o subdominio para la aplicación.
• Un certificado HTTPS válido.
• Un usuario o grupo autorizado en el backend de identidades.
• Acceso al archivo configuration.yml de Authelia.
• Control sobre el archivo Docker Compose o el cortafuegos de la aplicación.

El dominio público de la aplicación debe utilizar HTTPS. También debe quedar incluido dentro de uno de los dominios declarados en session.cookies. Por ejemplo, una cookie configurada para example.com puede utilizarse con app.example.com y auth.example.com.

No utilices dominios públicos compartidos completos, como duckdns.org, como dominio de la cookie. Debes emplear el subdominio que te pertenezca, como miservidor.duckdns.org.

Cómo cerrar el acceso directo al puerto de la aplicación

La protección de Authelia pierde buena parte de su utilidad si alguien puede evitar el proxy entrando directamente mediante una dirección como:

http://IP_DEL_SERVIDOR:8080

Si la aplicación se ejecuta en Docker, elimina la sección ports que publica su puerto en el host:

services:
  mi-aplicacion:
    image: imagen/de/la-aplicacion:version
    container_name: mi-aplicacion
    restart: unless-stopped
    networks:
      - proxy
    expose:
      - "8080"

networks:
  proxy:
    external: true

La directiva expose es opcional. Sirve para documentar el puerto utilizado por el contenedor, pero no constituye una barrera de seguridad. Los contenedores conectados a la misma red pueden comunicarse aunque esta sección no aparezca.

Lo realmente importante es no utilizar una asignación como:

ports:
  - "8080:8080"

Después de recrear el contenedor, el servicio dejará de escuchar en el puerto 8080 del host y solamente será accesible mediante su nombre dentro de la red Docker.

Si la aplicación se ejecuta en otro servidor y necesitas mantener el puerto abierto, utiliza el cortafuegos para permitir conexiones únicamente desde la dirección IP del proxy inverso.

Cómo conectar la aplicación a la red del proxy

La aplicación, Authelia y el proxy deben compartir al menos una red. Comprueba primero si ya existe:

docker network inspect proxy

Si todavía no la has creado:

docker network create proxy

Añade la red como externa en el archivo Compose de la aplicación:

networks:
  proxy:
    external: true

Después, recrea el servicio:

docker compose up -d

Desde ese momento, el proxy podrá localizar la aplicación mediante su nombre de servicio o de contenedor:

http://mi-aplicacion:8080

No utilices la dirección IP interna asignada por Docker porque puede cambiar cada vez que se recree el contenedor.

Si la aplicación también utiliza una base de datos, esta no necesita formar parte de la red del proxy. Puedes mantener una segunda red privada para comunicar exclusivamente la aplicación con PostgreSQL, MariaDB o el servicio correspondiente.

Cómo crear la política de acceso de la aplicación

Las políticas se configuran en el apartado access_control del archivo configuration.yml. Para exigir 2FA a todos los usuarios registrados:

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

Si solamente un grupo debe poder entrar:

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

También puedes establecer distintos niveles:

• deny: bloquea el acceso.
• bypass: permite acceder sin autenticación.
• one_factor: exige usuario y contraseña.
• two_factor: añade un segundo factor.

Authelia evalúa las reglas secuencialmente y aplica la primera coincidencia. Por eso, las políticas destinadas a un dominio, grupo o ruta concreta deben aparecer antes que las reglas generales.

Por ejemplo:

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

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

En este caso, el panel exige 2FA a los administradores y la regla general se aplica después al resto de subdominios.

No necesitas declarar el portal auth.example.com como bypass si su Proxy Host no utiliza la comprobación de Authelia. Proteger el portal mediante su propia autorización podría generar un bucle de redirección.

Cómo comprobar la configuración de Authelia

Antes de reiniciar el servicio, valida el archivo:

docker exec authelia authelia config validate --config /config/configuration.yml

Si no aparecen errores, reinicia Authelia:

docker restart authelia

Después, revisa sus registros:

docker logs --tail=200 authelia

Los errores de sangrado en YAML son habituales. Utiliza espacios en lugar de tabulaciones y comprueba que domain, policy y subject estén dentro de la misma regla.

Cómo conectar la aplicación al proxy inverso

En Nginx Proxy Manager, crea un Proxy Host dirigido al nombre interno del contenedor:

• Domain Names: app.example.com
• Scheme: http
• Forward Hostname/IP: mi-aplicacion
• Forward Port: 8080
• SSL Certificate: certificado válido para el dominio
• Force SSL: activado

En la pestaña Advanced, incluye los snippets oficiales:

include /snippets/authelia-location.conf;

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

El snippet actual consulta el endpoint /api/authz/auth-request. No reutilices ejemplos antiguos basados en /api/verify.

Si todavía no has preparado estos archivos, consulta la guía completa para integrar Authelia con Nginx Proxy Manager.

Qué ocurre con el login propio de la aplicación

Forward Auth decide si una petición puede llegar hasta la aplicación, pero no crea automáticamente una sesión dentro de ella. Por tanto, pueden darse tres situaciones:

• Aplicación sin login: Authelia se convierte en su única barrera de acceso.
• Aplicación con login propio: el usuario supera Authelia y después introduce las credenciales de la aplicación.
• Aplicación compatible con OIDC o encabezados fiables: puede reutilizarse la identidad de Authelia y evitar el segundo formulario.

Si la aplicación admite OpenID Connect, normalmente será preferible utilizar esa integración para conseguir un inicio de sesión único real. Forward Auth sigue siendo útil para aplicaciones antiguas, paneles sencillos o servicios que no admiten proveedores de identidad.

Por ejemplo, puedes emplear este sistema para proteger Open WebUI con contraseña, aunque la integración más adecuada dependerá de las funciones de autenticación disponibles en la versión instalada.

Cómo tratar APIs, aplicaciones móviles y WebSockets

Las aplicaciones móviles y algunos clientes de escritorio no pueden mostrar el portal de Authelia ni seguir correctamente sus redirecciones. En estos casos, proteger toda la API mediante Forward Auth puede impedir que el cliente se conecte.

Las opciones más seguras son:

• Utilizar OpenID Connect si la aplicación y el cliente lo admiten.
• Mantener la autenticación nativa de la API.
• Crear una excepción limitada a una ruta concreta que disponga de su propia protección.
• Utilizar una VPN para acceder al servicio sin publicarlo directamente.

No excluyas una API completa solamente para hacer funcionar una aplicación móvil. Si necesitas permitir un webhook o una comprobación de salud, limita la regla mediante resources:

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

Esta excepción solo es aceptable si el endpoint valida una firma, token o secreto independiente.

Si la aplicación utiliza WebSockets, añade dentro de su bloque location:

include /snippets/websocket.conf;

Cuando se escribe un bloque location manual en la pestaña Advanced de Nginx Proxy Manager, activar solamente el interruptor Websockets Support puede no surtir efecto.

Por qué debes tener cuidado con los bypass por dirección IP

Authelia puede aplicar políticas distintas según la red desde la que llega el usuario. Sin embargo, estas reglas dependen de la dirección incluida en X-Forwarded-For.

El proxy debe eliminar cualquier valor enviado directamente por el cliente y sustituirlo por la dirección real. De lo contrario, un atacante podría falsificar su IP de origen para coincidir con una red autorizada.

No configures un acceso sin autenticación para toda tu red doméstica hasta comprobar que:

• Solo los proxies de confianza pueden modificar los encabezados reenviados.
• Nginx Proxy Manager reconoce correctamente la IP real.
• Cloudflare u otros proxies intermedios están declarados como fiables.
• Una cabecera manipulada desde Internet no activa la política de bypass.

Siempre que sea posible, resulta más seguro mantener one_factor dentro de la red local y reservar two_factor para las conexiones externas.

Cómo comprobar que la aplicación está realmente protegida

La prueba no termina cuando aparece el portal de Authelia. Debes verificar que no exista otra ruta capaz de alcanzar la aplicación.

Primero, revisa los puertos publicados:

docker ps --format 'table {{.Names}}\t{{.Ports}}'

El contenedor protegido no debería mostrar una asignación como 0.0.0.0:8080->8080/tcp.

Después, sigue estas comprobaciones:

1. Cierra la sesión de Authelia o utiliza una ventana privada.
2. Abre https://app.example.com.
3. Confirma que el navegador te redirige al portal.
4. Comprueba que solicita el nivel de autenticación configurado.
5. Prueba con un usuario que no pertenezca al grupo autorizado.
6. Intenta acceder directamente mediante la IP y el antiguo puerto.
7. Revisa las rutas personalizadas, APIs, webhooks y conexiones WebSocket.

También puedes inspeccionar la respuesta sin iniciar sesión:

curl -I https://app.example.com

Deberías recibir una redirección hacia el portal de Authelia, normalmente mediante un código HTTP 302.

Repite estas pruebas después de actualizar Authelia, cambiar el proxy, modificar las políticas o añadir una ubicación personalizada.

Errores frecuentes al proteger una aplicación con Authelia

La aplicación continúa siendo accesible mediante la IP

El contenedor todavía publica su puerto en el host o el cortafuegos permite conexiones directas. Elimina la sección ports, recrea el contenedor y comprueba nuevamente la lista de puertos.

Aparece un error 502 Bad Gateway

El proxy no puede localizar la aplicación. Verifica que ambos contenedores estén conectados a la misma red y que el nombre del servicio y el puerto interno sean correctos.

Authelia muestra Access Denied después del login

El usuario se ha autenticado correctamente, pero no cumple la política. Comprueba el nombre del grupo, el dominio solicitado y el orden de las reglas.

El navegador entra en un bucle de redirección

Revisa el uso de HTTPS, el dominio de la cookie, authelia_url y los encabezados reenviados por el proxy. Comprueba también que el portal no esté protegido mediante su propio auth_request.

La aplicación vuelve a pedir usuario y contraseña

No se trata necesariamente de un error. Forward Auth protege la entrada, pero no inicia automáticamente una sesión dentro de la aplicación. Necesitarás OIDC o una integración mediante encabezados de confianza para eliminar ese segundo login.

La web funciona, pero la aplicación móvil no conecta

El cliente probablemente no puede seguir la redirección hacia Authelia. Comprueba si admite OIDC o conserva la autenticación nativa de la API sin aplicar excepciones demasiado amplias.

Algunas funciones en tiempo real dejan de responder

La aplicación utiliza WebSockets y el proxy no conserva las cabeceras necesarias. Incluye websocket.conf dentro del mismo bloque protegido.

Una ruta personalizada permite entrar sin autenticación

Las ubicaciones creadas desde Custom Locations pueden no heredar la autorización. Decláralas en Advanced e incluye explícitamente authelia-authrequest.conf.

Proteger una aplicación web con Authelia no consiste solamente en mostrar un formulario antes de entrar. La seguridad real requiere cerrar el puerto original, dirigir todo el tráfico a través del proxy, crear una política específica y comprobar que APIs, rutas personalizadas o encabezados manipulados no permitan evitar la autenticación.

Una vez completadas estas comprobaciones, podrás añadir contraseña y 2FA a servicios antiguos o demasiado básicos sin modificar su código, manteniendo un punto de acceso centralizado y controlado.