Proteger Navidrome con Authentik (vía Proxy Provider)
Introducción
Este artículo documenta la integración de Navidrome detrás de Authentik, utilizando Caddy como proxy inverso, con el objetivo de añadir una capa externa de control de acceso sin modificar el sistema de autenticación interno de la aplicación.
La integración se sitúa en el flujo cliente → Caddy → Authentik (Proxy Provider) → Navidrome, actuando Authentik como barrera previa al acceso web. En este escenario, la autenticación no queda completamente centralizada, ya que Navidrome mantiene su propio sistema de login una vez superada la capa de Authentik.
El enfoque prioriza control perimetral y trazabilidad, asumiendo explícitamente la coexistencia de dos pantallas de autenticación.
Nota técnica: Authentik no está diseñado para proteger flujos binarios, peticiones HEAD o streaming con rangos. Por este motivo, el control de acceso de estos endpoints debe implementarse en el reverse proxy.
Enfoque general / Arquitectura
La protección se implementa mediante un Proxy Provider de Authentik en modo forward auth, integrado en Caddy como punto único de entrada HTTP.
Características clave del enfoque:
- Authentik controla el acceso inicial a nivel de proxy.
- Navidrome conserva su autenticación nativa y gestión de usuarios.
- Se produce una doble autenticación (Authentik + Navidrome).
- No se realiza federación de identidad ni SSO real entre ambos sistemas.
Este diseño es deliberado: se añade una capa de seguridad externa sin alterar el comportamiento interno de Navidrome ni su modelo de usuarios.
Requisitos previos
Dependencias que condicionan el funcionamiento y las decisiones tomadas:
- Authentik operativo con Proxy Provider funcional.
- Outpost desplegado y accesible desde Caddy.
- Caddy como proxy inverso principal del stack.
- Directiva de Authentik para Caddy ya validada.
- Navidrome funcionando correctamente sin Authentik delante (estado base conocido).
Instalación y explicación paso a paso
Crear la aplicación en Authentik
La integración comienza definiendo una Application específica para Navidrome dentro de Authentik. Esta aplicación actúa como punto de unión entre el servicio protegido y el proveedor de autenticación.
Proceso seguido:
-
Acceso al panel de administración de Authentik.
-
Navegación a Applications y uso de la opción Create with Provider.
-
Definición de la aplicación:
- Nombre identificativo del servicio.
- Slug coherente con el nombre.
- Metadatos opcionales (descripción, icono).
-
Selección de Proxy Provider como tipo de proveedor asociado.
Esta elección permite colocar Authentik delante de Navidrome sin modificar su lógica interna.
Configurar el Proxy Provider
El Proxy Provider se configura para actuar como barrera de autenticación previa al acceso web del servicio.
Aspectos relevantes de la configuración:
- Nombre descriptivo del proveedor, alineado con la aplicación.
- Selección del flujo de autenticación habitual del entorno.
- Activación del modo Forward auth (single application).
- Definición del External host apuntando al dominio público de Navidrome.
No se definen rutas excluidas del proceso de autenticación. Todas las peticiones quedan sujetas al control de Authentik.
La integración con Caddy se realiza mediante la directiva específica de Authentik, aplicada antes del reverse_proxy hacia Navidrome.
Asignar la aplicación al Outpost
Una vez creada la aplicación y su proveedor, es necesario asociarla a un Outpost operativo:
- Acceso a la sección Outposts en Authentik.
- Edición del Outpost en uso (habitualmente el Embedded Outpost en despliegues con contenedores).
- Asociación explícita de la aplicación de Navidrome.
Esta asignación permite que el Outpost gestione correctamente las peticiones autenticadas.
Consideraciones sobre clientes externos y enlaces compartidos
En esta integración no se utilizan rutas sin autenticar en Authentik. El control de qué endpoints quedan protegidos y cuáles no se traslada explícitamente al reverse proxy (Caddy).
La exclusión de endpoints necesarios para streaming y clientes externos se realiza exclusivamente en Caddy, evitando que Authentik intercepte peticiones que no están diseñadas para flujos interactivos.
Este enfoque permite:
- Mantener intacto el comportamiento de endpoints binarios y de streaming.
- Evitar problemas con peticiones
HEAD, rangos (Range) y análisis de flujo. - Garantizar compatibilidad con clientes Subsonic y herramientas externas.
- Eliminar dependencias de Unauthenticated Paths en el IdP.
La configuración completa y recomendada del Caddyfile para Navidrome con Authentik se mantiene versionada en Gitea:
La explicación detallada de esta decisión y sus implicaciones técnicas se documenta en el propio repositorio.
Desarrollo
Qué se hizo y por qué
Se define una Application en Authentik asociada a un Proxy Provider, apuntando al dominio público de Navidrome. El proveedor se configura para autenticar todas las peticiones entrantes sin excepciones de ruta.
La decisión de no eliminar ni sustituir el login interno de Navidrome responde a varios factores:
El resultado es una protección perimetral clara, a costa de una experiencia de usuario menos transparente.
Validación
Comprobaciones mínimas realizadas:
- Acceso web redirige correctamente al flujo de autenticación de Authentik.
- Tras autenticación válida, se muestra la pantalla de login propia de Navidrome.
- Accesos directos al backend quedan inaccesibles sin pasar por Caddy.
- Logs de Authentik y Caddy sin errores de forward auth.
- El Outpost registra correctamente la aplicación.
Decisiones importantes o problemas detectados
- La autenticación no está centralizada: existen dos sistemas de login independientes.
- No hay SSO real ni sincronización de identidades.
- El modelo es robusto a nivel perimetral, pero penaliza la experiencia de usuario.
- La gestión de clientes no web y accesos automáticos requiere un diseño separado.