Cómo instalar Authentik para SSO auto-alojado

Actualizado: 2026-07-17

Instalar Authentik con Docker Compose despliega un IdP (identity provider, el servicio que verifica quién eres y qué permisos tienes) que centraliza el inicio de sesión único, SSO (un solo login que abre varias aplicaciones sin repetir credenciales), usando OAuth2, OIDC, SAML y LDAP (los protocolos estándar de autenticación y directorio que ya hablan la mayoría de aplicaciones empresariales). 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.

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^[1]: muy 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: 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^[2] 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, y terminó en 2025.10, cuando la caché, la cola de tareas y las conexiones WebSocket también pasaron a PostgreSQL (esta última usando NOTIFY/LISTEN en lugar de pub/sub de Redis). El propio equipo de Authentik documenta el cambio en su blog técnico^[3].

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:2025.10
    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"

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 varios minutos. 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^[4] 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. Varios equipos han 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.

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 muy 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^[2], repositorio de Authentik en GitHub^[5], blog técnico de Authentik sobre la eliminación de Redis^[3], documentación de Traefik sobre el middleware ForwardAuth^[4].

Fuentes

1. Keycloak
2. documentación oficial de Authentik
3. su blog técnico
4. middleware de tipo forwardAuth
5. repositorio de Authentik en GitHub

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