Cómo instalar Authentik para SSO auto-alojado

Probado con Authentik 2026.8.1 · Docker Compose · verificado 2026-09-02

Actualizado: 2026-09-02

Instalar Authentik con Docker Compose despliega un IdP (identity provider: verifica quién eres y qué permisos tienes) que centraliza el inicio de sesión único, SSO: un solo login para todas las aplicaciones conectadas. Usa OAuth2, OIDC, SAML y LDAP, los protocolos estándar de autenticación y directorio del software empresarial. El stack mínimo actual son tres contenedores: PostgreSQL, servidor y worker, sin Redis obligatorio desde la versión 2025.10. En una tarde se tiene login web y forward auth (autenticación delegada: un proxy inverso como Traefik consulta a Authentik antes de dejar pasar cada petición) funcionando en un par de servicios.

Esta guía también está disponible en inglés: How to Install Authentik for Self-Hosted SSO.

Puntos clave

• Desde la versión 2025.10, Authentik elimina por completo la dependencia de Redis: el stack mínimo es PostgreSQL + servidor + worker (tres contenedores en lugar de cuatro).
• El forward auth con Traefik es el caso de uso más común: proteger servicios web internos sin modificar cada aplicación.
• Tres problemas clásicos de primera instalación: configuración de dominio/URLs, manejo de cookies en subdominios y volúmenes persistentes para PostgreSQL.
• Encaja bien para organizaciones pequeñas y medianas; para miles de usuarios o políticas complejas, Keycloak sigue siendo más potente.
• Nunca saltar versiones major.minor en las actualizaciones: hay que ir una a una.

Qué ha cambiado desde la 2025.10

Esta guía se escribió sobre la rama 2025.10, la primera sin Redis. La rama actual es la 2026.8. La 2026.8.0 salió el 18 de agosto de 2026. La 2026.8.1, el 1 de septiembre de 2026, es la etiqueta que fija hoy el compose.yml oficial.

Comprobado el 2 de septiembre de 2026 contra las notas de la versión 2026.8^[1] y las releases del repositorio^[2]. Nada de lo anterior sobre la arquitectura sin Redis cambia; lo que sigue se suma:

• Cambio que rompe el forward auth si no lo preparas: desde 2026.8 el servidor solo acepta las cabeceras X-Forwarded-Proto, X-Forwarded-Host y X-Forwarded-For cuando la conexión llega desde una red de proxy de confianza. Toda dirección o red desde la que Traefik o Nginx conecten directamente con Authentik tiene que estar en AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS; si no, Authentik verá la petición como HTTP plano y las redirecciones fallarán. Revísalo antes de actualizar, no después.
• Otros dos cambios incompatibles: la orden hash_password ya no acepta la contraseña como argumento (pide de forma interactiva) y desaparece la opción de impedir dispositivos WebAuthn duplicados, sin nada que configurar.
• Novedades de la 2026.8: gestión de accesos privilegiados (los usuarios solicitan acceso a una aplicación o a un entitlement y un aprobador lo concede con caducidad), cambio de una sesión iniciada a otra desde la interfaz de usuario, baja programada de usuarios (desactivación o borrado a fecha y hora), atributos de objeto tipados (texto, número y booleano con validación) para usuarios, grupos y entitlements, y mapas de eventos con un mapa base incluido que no hace peticiones externas, pensado para entornos aislados. En OAuth 2.0 el proyecto ha obtenido la certificación OpenID Certified y añade intercambio de tokens, delegación on-behalf-of, registro dinámico de clientes y tokens de identidad ligados a clave. Las cuentas de agente (cuentas de servicio que actúan en nombre de un usuario) son función Enterprise.
• AUTHENTIK_POSTGRESQL__CONN_OPTIONS sigue deprecada en 2026.8 y las notas mantienen que «se eliminará en una versión próxima». Si aún la tienes, quítala.
• Actualizar con Compose, tal como lo describen las notas: wget -O docker-compose.yml https://goauthentik.io/version/2026.8/lifecycle/container/compose.yml y docker compose up -d. Con la regla de esta guía de no saltar versiones, desde 2025.10 el camino pasa por 2025.12, 2026.2 y 2026.5 antes de 2026.8. El compose oficial sigue usando PostgreSQL 16.

Por qué Authentik y no otra cosa

La decisión entre Authentik, Keycloak, Zitadel y soluciones comerciales como Auth0 depende del contexto, pero para auto-alojado pequeño y medio la elección tiene matices claros:

• Keycloak^[3]: potente pero pesado. Interfaz administrativa con curva de aprendizaje que frena a equipos sin dedicación de tiempo.
• Zitadel: elegante pero más joven y con ecosistema menor.
• Auth0: excelente pero dejó de ser opción realista para quien quiere auto-alojar.

Authentik ocupa el hueco intermedio. Es suficientemente completo para casos reales, con buen soporte de SAML y OAuth2, con forward auth útil para proteger servicios detrás de Traefik o Nginx, y con consumo de recursos manejable. Una instancia pequeña corre cómoda con 2 GB de memoria y un par de núcleos. La documentación oficial de Authentik^[4] detalla los requisitos completos por tamaño de despliegue.

La arquitectura desde 2025.10

Un cambio importante que conviene entender antes de instalar: en la versión 2025.10, Authentik eliminó Redis del todo, no lo hizo opcional. Durante años la arquitectura mínima era PostgreSQL + Redis + servidor + worker.

El proceso empezó en la versión 2024.6, sustituyendo los locks de Redis por locks de PostgreSQL. Terminó en 2025.10, cuando la caché, la cola de tareas y las conexiones WebSocket también pasaron a PostgreSQL, estas últimas usando NOTIFY/LISTEN en lugar de pub/sub de Redis. El propio equipo de Authentik documenta el cambio en su blog técnico^[5].

Esta simplificación tiene efectos prácticos, con matices:

1. El stack baja de cuatro contenedores a tres, reduciendo superficie de configuración y de fallos.
2. Quien instala por primera vez no tiene que explicar por qué hay un Redis colgando del servicio de identidad.
3. A cambio, Authentik consume aproximadamente un 50% más de conexiones a PostgreSQL que antes, porque absorbe el trabajo que hacía Redis. En instancias con límites de conexión ajustados conviene revisar max_connections en PostgreSQL antes de actualizar.
4. Si PostgreSQL exige TLS, Authentik desde 2025.10 requiere TLS 1.3 o la extensión Extended Master Secret para conectar.

El despliegue básico

El archivo docker-compose.yml parte del oficial publicado por Authentik pero simplificado. Define:

• Un servicio postgresql con versión 16.
• Un servicio server con la imagen ghcr.io/goauthentik/server y comando server.
• Un servicio worker con la misma imagen y comando worker.

El servidor expone los puertos 9000 y 9443, que son los que Traefik o Nginx usan para forward auth.

Las variables de entorno mínimas son:

• AUTHENTIK_SECRET_KEY: cadena aleatoria larga usada para firmar tokens.
• AUTHENTIK_POSTGRESQL__HOST: apunta al servicio de base de datos.
• AUTHENTIK_POSTGRESQL__USER, AUTHENTIK_POSTGRESQL__NAME, AUTHENTIK_POSTGRESQL__PASSWORD.

En despliegues serios, sacar la contraseña y el secret a un gestor de secretos o a un archivo .env ignorado por git (ver nuestra guía de variables de entorno y secretos en Docker Compose).

services:
  server:
    image: ghcr.io/goauthentik/server:2026.8.1
    command: server
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
    ports:
      - "9000:9000"
      - "9443:9443"
    depends_on:
      - postgresql
    deploy:
      resources:
        limits:
          memory: 768M
          cpus: "1.5"

La etiqueta fijada arriba es la 2026.8.1 (1 de septiembre de 2026), la misma que usa el compose.yml oficial de la rama 2026.8; cuando se escribió esta guía era 2025.10. Si Authentik va detrás de Traefik o Nginx, añade también AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS con la red desde la que conecta el proxy. Desde 2026.8 las cabeceras X-Forwarded-* solo se aceptan de proxies de confianza (detalle en la sección anterior).

Un detalle útil: poner límites de memoria y CPU desde el principio. El servidor puede tener picos durante logins masivos o sincronizaciones LDAP, y sin límite declarado puede afectar a otros servicios en el mismo host.

El primer arranque y las migraciones

Cuando el servidor arranca por primera vez, ejecuta automáticamente las migraciones de base de datos. Este proceso puede tardar minutos, no segundos. Un punto de fricción típico es arrancar servidor y worker a la vez. En la primera instalación y en actualizaciones mayores, lo ideal es:

1. Arrancar solo el servicio postgresql y esperar a que su healthcheck esté listo.
2. Arrancar el server y ver en los logs (docker compose logs -f server) que termina las migraciones (línea final del tipo Migrations applied).
3. Arrancar el worker.

Si servidor y worker intentan aplicar migraciones al mismo tiempo pueden aparecer bloqueos de PostgreSQL que requieren matar sesiones manualmente con SELECT pg_terminate_backend(pid). Este patrón también aplica en actualizaciones secuenciales entre versiones mayores. Nunca se pueden saltar major.minor, hay que ir una a una (por ejemplo, de 2025.8 a 2025.10, no directo de 2025.4 a 2025.10).

Tras las migraciones, la interfaz de administración está en el puerto 9000 bajo /if/flow/initial-setup/ la primera vez. Allí se crea el usuario admin inicial. Usar un correo real y guardar la contraseña en un gestor.

Forward auth con Traefik

El caso de uso más común al adoptar Authentik es proteger servicios web internos detrás de un proxy inverso (el componente que recibe todas las peticiones HTTP y las reparte hacia el contenedor correcto). El patrón se llama forward auth: Traefik recibe la petición, la redirige a Authentik para verificar que hay sesión válida, y si no la hay envía al usuario al login. Si ya tienes Traefik desplegado, nuestra guía de instalación de Traefik con Docker Compose cubre el proxy inverso desde cero.

La configuración en Authentik sigue estos pasos:

1. Crear un proxy provider con forward auth single application o forward auth domain.
2. Crear una aplicación asociada.
3. Crear un outpost que exponga el endpoint de forward auth.

Del lado de Traefik, se define un middleware de tipo forwardAuth^[6] apuntando al outpost, y se aplica ese middleware a cualquier router que quiera quedar protegido.

Un patrón que uso es tener dos cadenas de middlewares predefinidas:

• chain-base: para servicios públicos sin autenticación.
• chain-oauth: para servicios protegidos que pasan por Authentik.

Esta separación hace que añadir o quitar protección de un servicio sea cambiar una etiqueta, no rehacer la configuración.

Puntos de fricción típicos

Hay tres problemas que casi todo el mundo encuentra la primera vez:

1. Configuración de dominio y URLs. Authentik necesita saber desde qué dominio se le accede para generar correctamente las redirecciones. La variable AUTHENTIK_HOST y la configuración de brand dentro de la interfaz tienen que coincidir con el dominio real. Si pones authentik.ejemplo.com en Traefik pero Authentik cree que está en localhost, las redirecciones devuelven al usuario a localhost y el login no funciona.
2. Manejo de cookies en subdominios. Para que una sesión de Authentik proteja servicios en subdominios distintos, las cookies tienen que estar configuradas con el dominio padre. La solución es configurar el proxy provider con la opción de cookie domain apuntando al dominio raíz (por ejemplo .ejemplo.com, con el punto inicial).
3. Almacenamiento de datos. La base de datos de PostgreSQL es crítica y debe ir a un volumen persistente (revisa nuestra guía de volúmenes y bind mounts en Docker) con copias de seguridad configuradas, por ejemplo con Restic. Más de un equipo ha perdido la configuración entera de Authentik por tener el volumen en un tmpfs o por eliminar el volumen al hacer compose down -v por error.

Forward auth que deja de funcionar tras actualizar: el cambio de cabecera

Si el forward auth con Traefik te funcionaba y deja de hacerlo justo después de actualizar Authentik, casi seguro no has roto la configuración: cambió la cabecera.

Authentik 2025.12.5 y 2026.2.3 incluyen una corrección de seguridad que elimina el soporte de la cabecera no estándar X-Original-Uri. Las versiones antiguas del plugin de forward auth para Traefik enviaban exactamente esa cabecera, así que dejan de funcionar con esas versiones de Authentik y posteriores. La solución no es tocar el middleware: es actualizar el plugin, que ya envía la cabecera correcta X-Original-Url y sigue siendo compatible con versiones anteriores de Authentik.

Dos comprobaciones más que evitan sustos

• Limpia las cabeceras X-Authentik-* entrantes. Si un cliente puede enviarlas y tu proxy las deja pasar hasta la aplicación, puede suplantar identidad. Un plugin de forward auth serio las elimina antes de reenviar; verifica que el tuyo lo hace.

• AUTHENTIK_POSTGRESQL__CONN_OPTIONS está deprecada desde la rama 2026.5 y en 2026.8 sigue marcada para eliminarse «en una versión próxima». Si la tienes en tu .env, quítala ahora y no en mitad de una actualización urgente.

Nota sobre Redis, porque genera confusión al leer guías antiguas: desde 2025.10 no hace falta. La caché, el outpost embebido y los WebSocket se movieron a PostgreSQL, y los ajustes de Redis se pueden borrar de la configuración.

Preguntas frecuentes

¿Hace falta instalar Redis para usar Authentik?

No, desde la versión 2025.10 no. Authentik migró toda la caché, la cola de tareas y las notificaciones WebSocket a PostgreSQL, así que el stack mínimo son tres contenedores: PostgreSQL, servidor y worker. En versiones anteriores a 2025.10, Redis sí era obligatorio.

¿Es Authentik mejor que Keycloak?

Depende del tamaño. Para equipos pequeños o medianos, Authentik suele instalarse y mantenerse más rápido gracias a una interfaz más simple. Para organizaciones grandes con miles de usuarios, federación compleja o requisitos estrictos de cumplimiento, Keycloak ofrece más políticas y una comunidad más veterana.

Conclusión

Authentik ofrece la mejor relación entre esfuerzo de instalación y capacidades obtenidas en el espacio de identidad auto-alojada. Una tarde basta para tener una instancia funcional con login web y forward auth en un par de servicios. Si estás evaluando identidad auto-alojada y no tienes requisitos extremos de escala o cumplimiento específicos, Authentik es el primer candidato a probar.

Donde pausar y pensar: si tu organización tiene usuarios externos, partners o clientes que también se van a autenticar. Los requisitos de disponibilidad y de identidad federada cambian mucho cuando el SSO deja de ser interno. La buena noticia es que esa revisión puede hacerse con Authentik ya funcionando en tareas internas, sin necesidad de elegir la herramienta final desde el día uno.

Fuentes: documentación oficial de Authentik^[4], repositorio de Authentik en GitHub^[7], blog técnico de Authentik sobre la eliminación de Redis^[5], documentación de Traefik sobre el middleware ForwardAuth^[6].

Fuentes

1. notas de la versión 2026.8
2. releases del repositorio
3. Keycloak
4. documentación oficial de Authentik
5. su blog técnico
6. middleware de tipo forwardAuth
7. repositorio de Authentik en GitHub

Ruta: Self-hosting con Docker: de cero a producción