Cómo instalar Authentik para SSO auto-alojado

Actualizado: 2026-05-03

Authentik es el proveedor de identidad auto-alojado que más recomendaciones ha recibido en los últimos dos años de gente con la que trabajo. Combina OAuth2, SAML, LDAP y forward authentication en un solo paquete, con una interfaz razonable y una curva de aprendizaje mucho más amable que la de Keycloak. Este artículo cubre la instalación concreta con Docker Compose, las decisiones de arquitectura actuales y los puntos donde la mayoría de gente se tropieza la primera vez.

Puntos clave

• Desde la versión 2025.10, Authentik elimina la dependencia obligatoria de Redis: el stack mínimo es PostgreSQL + servidor + worker (tres contenedores en lugar de cuatro).
• El forward authentication 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: 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 authentication ú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 arquitectura desde 2025.10

Un cambio importante que conviene entender antes de instalar: desde la versión 2025.10, Authentik eliminó la dependencia obligatoria de Redis. Durante años la arquitectura mínima era PostgreSQL + Redis + servidor + worker. Ahora basta con PostgreSQL + servidor + worker, y Redis se ha convertido en opcional para casos de alta concurrencia.

Esta simplificación tiene dos efectos prácticos:

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.

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 authentication.

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.

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 servidor.
2. Ver que termina las migraciones en los logs.
3. Arrancar el worker.

Si ambos intentan aplicar migraciones al mismo tiempo pueden aparecer bloqueos de PostgreSQL que requieren matar sesiones manualmente. Este patrón también aplica en actualizaciones secuenciales entre versiones mayores: nunca se pueden saltar major.minor, hay que ir una a una.

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 authentication con Traefik

El caso de uso más común al adoptar Authentik es proteger servicios web internos detrás de un proxy. El patrón se llama forward authentication: 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.

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 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.
3. Almacenamiento de datos. La base de datos de PostgreSQL es crítica y debe ir a un volumen persistente con copias de seguridad configuradas. Varios equipos han perdido configuración entera de Authentik por tener el volumen en un tmpfs o por eliminar el volumen al hacer compose down con la bandera incorrecta.

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 authentication 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.