Authentik: SSO autohospedado con Docker y Traefik

Un inicio de sesión para todas las aplicaciones que aloja

Authentik es un servidor SSO (inicio de sesión único) autohospedado: los usuarios inician sesión una vez y todas las aplicaciones que están detrás aceptan esa sesión en lugar de solicitar su propia contraseña. La instalación usa un archivo oficial de Docker Compose y dos secretos generados. La parte que requiere más trabajo viene después: apuntar un proxy inverso hacia él y colocar una aplicación existente detrás de la autenticación delegada.

Authentik se ejecuta como tres servicios en ese archivo de Compose: una base de datos PostgreSQL, un proceso server y un proceso worker. El contenedor del servidor también ejecuta el outpost integrado, que es el componente que responde a «¿esta solicitud tiene una sesión iniciada?» para cada aplicación protegida. La versión 2026.5 es la versión actual en julio de 2026, y el proyecto solicita un host con al menos 2 núcleos de CPU y 2 GB de RAM. Considere esto como el mínimo. PostgreSQL y el worker mantienen memoria ocupada después de que el equipo lleva un día en funcionamiento.

Qué necesita antes de empezar

Necesita Docker Engine con el complemento Compose v2, que puede confirmar con docker compose version. Si muestra un error en lugar de una versión, instale el complemento antes de continuar; los conceptos básicos se explican en ejecutar aplicaciones con Docker Compose en un VPS. También necesita un registro DNS A que apunte al servidor, auth.example.com en los ejemplos siguientes, porque Authentik construye sus URL de redireccionamiento a partir del nombre de host que usó el navegador.

Ejecute la pila como un usuario normal del grupo docker, no como root. La pertenencia a ese grupo equivale a root en el host, así que asígnela a una sola cuenta de implementación y a ninguna otra, como se explica en cuentas de usuario con privilegios mínimos en un VPS.

Instalar con el archivo oficial de Compose

sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

docker compose ps debe mostrar tres contenedores. postgresql debe indicar healthy y server debe indicar worker. running debe indicar running. El primer inicio ejecuta las migraciones de la base de datos, así que espere un minuto antes de que la interfaz web responda.

Los dos valores generados son importantes, pero por motivos diferentes. PG_PASS es la contraseña de PostgreSQL y tiene un límite máximo de 99 caracteres. AUTHENTIK_SECRET_KEY firma las sesiones y los tokens, por lo que cambiarlo posteriormente cierra la sesión de todos los usuarios e invalida todos los tokens de API emitidos. Mantenga .env con el modo 600 y guarde una copia en un lugar seguro, porque una base de datos restaurada sin su clave secreta correspondiente es una base de datos en la que nadie puede iniciar sesión.

El archivo de Compose lee ambos valores con el formato ${PG_PASS:?database password required}, por lo que Compose no se inicia si falta el archivo. Ejecutar docker compose up -d desde el directorio incorrecto muestra required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required y se detiene. Ese mensaje indica un problema de ruta, no un problema de configuración.

Los valores del entorno importantes

Todo lo demás va en el mismo archivo .env. Authentik asigna un guion bajo doble a una clave de configuración anidada, por lo que AUTHENTIK_EMAIL__HOST establece email.host. Un guion bajo simple se ignora sin mostrar ninguna advertencia. Esta es la razón más común por la que una configuración parece no tener efecto.

• AUTHENTIK_BOOTSTRAP_PASSWORD establece la contraseña del usuario integrado akadmin durante el primer inicio, por lo que nunca debe introducirla en un formulario web público. AUTHENTIK_BOOTSTRAP_EMAIL y AUTHENTIK_BOOTSTRAP_TOKEN establecen de la misma forma la dirección de ese usuario y un token de API.
• COMPOSE_PORT_HTTP y COMPOSE_PORT_HTTPS cambian los puertos publicados de los valores predeterminados 9000 y 9443.
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS y AUTHENTIK_EMAIL__FROM configuran el correo saliente. Sin estos valores, Authentik intenta usar localhost en el puerto 25, por lo que los mensajes para restablecer contraseñas terminan con un error de conexión en el registro del worker.
• AUTHENTIK_LOG_LEVEL=debug activa el nivel de detalle necesario mientras un flujo de inicio de sesión funciona de forma incorrecta. Vuelva a establecerlo en info después.
• AUTHENTIK_ERROR_REPORTING__ENABLED es false de forma predeterminada. Establézcalo en true solo si acepta enviar informes de errores al proveedor.

Estos son secretos almacenados en un archivo de texto sin cifrar. Proteja el directorio igual que cualquier otro almacén de credenciales. Un gestor de contraseñas, como una instancia de Vaultwarden autohospedada, es un lugar más adecuado para guardar la copia de recuperación que una nota en su portátil.

Primer inicio de sesión y cuenta de administrador

Abra http://SERVER_IP:9000 en un navegador. Authentik muestra el flujo de configuración inicial y le pide establecer una contraseña para el usuario predeterminado akadmin. Si ya estableció AUTHENTIK_BOOTSTRAP_PASSWORD, ese paso ya está completado y pasa directamente a la página de inicio de sesión.

Cree un usuario administrador normal para usted en Directory y después en Users, agréguelo al grupo authentik Admins e inicie sesión con esa cuenta. Mantenga akadmin como cuenta de emergencia, con una contraseña larga almacenada sin conexión. El trabajo diario con una cuenta integrada compartida destruye el registro de auditoría, porque todos los eventos indican akadmin y no quién los realizó.

Colocar Authentik detrás de su proxy inverso

Publicar el puerto 9000 en Internet funciona, pero necesita TLS (seguridad de la capa de transporte) y un nombre de host real. Si ya usa la configuración de Traefik como proxy inverso para varias aplicaciones de Compose, conecte Authentik a la misma red externa proxy mediante un archivo de sustitución. Cree docker-compose.override.yml junto a compose.yml:

services:
  server:
    networks:
      - default
      - proxy
    labels:
      traefik.enable: "true"
      traefik.docker.network: proxy
      traefik.http.routers.authentik.rule: Host(`auth.example.com`)
      traefik.http.routers.authentik.entrypoints: websecure
      traefik.http.routers.authentik.tls.certresolver: le
      traefik.http.services.authentik.loadbalancer.server.port: "9000"

networks:
  proxy:
    external: true

Aplíquelo con docker compose up -d. Compose combina automáticamente el archivo de sustitución, por lo que el servicio server conserva todo lo definido en el archivo oficial y obtiene las etiquetas. Compruébelo con curl -I https://auth.example.com/if/user/, que debería responder HTTP/2 200. Un 404 page not found de Traefik significa que el contenedor no está conectado a la red proxy y Traefik no puede dirigir el tráfico a un contenedor al que no puede acceder.

Cuando el nombre de host funcione, asocie los puertos publicados a 127.0.0.1 en el archivo de sustitución. Así, la única vía de acceso será el proxy.

Protege una aplicación con autenticación reenviada

El proveedor de proxy de Authentik tiene tres modos, y elegir el incorrecto puede costarte una hora. Proxy significa que el propio outpost reenvía el tráfico a la aplicación ascendente. Forward auth (single application) significa que tu propio proxy inverso sigue gestionando el tráfico y solo consulta a Authentik si la solicitud tiene una sesión iniciada. Forward auth (domain level) protege todas las aplicaciones de un mismo dominio principal con un solo proveedor, pero no permite definir reglas de autorización por aplicación. Si Traefik está delante, necesitas forward auth (single application).

En la interfaz web, abre Applications y después Providers, crea un Proxy Provider, elige el modo forward auth single application y establece el host externo en https://app.example.com. Crea una Application que apunte a ese proveedor. Después abre Outposts, edita authentik Embedded Outpost y mueve la nueva aplicación a sus aplicaciones seleccionadas. El outpost solo responde para las aplicaciones que se le han asignado. Por eso, si omites este último paso, un proveedor correctamente configurado no devuelve ninguna respuesta.

Define el middleware una sola vez, en el contenedor de Authentik, y haz referencia a él desde cada aplicación protegida:

      traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
      traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
      traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version

authResponseHeaders es la lista de encabezados que Traefik copia de la respuesta de Authentik a la solicitud que envía a la aplicación ascendente. Si la omites, la aplicación sigue protegida, pero no sabe quién es el usuario. Por tanto, todo lo que lea X-authentik-username para iniciar sesión automáticamente permanece sin sesión iniciada.

La aplicación protegida necesita dos routers, no uno:

    labels:
      traefik.enable: "true"
      traefik.http.routers.myapp.rule: Host(`app.example.com`)
      traefik.http.routers.myapp.entrypoints: websecure
      traefik.http.routers.myapp.tls.certresolver: le
      traefik.http.routers.myapp.middlewares: authentik@docker
      traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
      traefik.http.routers.myapp-auth.entrypoints: websecure
      traefik.http.routers.myapp-auth.tls.certresolver: le
      traefik.http.routers.myapp-auth.priority: "15"
      traefik.http.routers.myapp-auth.service: authentik

El segundo router es el elemento que normalmente se omite. Después de iniciar sesión, Authentik envía el navegador de vuelta a una ruta bajo /outpost.goauthentik.io/ en el hostname de la aplicación, no en auth.example.com. Sin un router que envíe ese prefijo de ruta al servicio de Authentik, la solicitud llega a la aplicación, que responde con 404, y el inicio de sesión no termina. El valor superior de priority hace que la regla de ruta específica tenga prioridad sobre la regla simple Host() en el mismo dominio.

Pruébalo en una ventana privada del navegador. Deberías ser redirigido a auth.example.com, iniciar sesión y volver a la aplicación. docker compose logs -f server, en el lado de Authentik, muestra un evento de autorización por cada intento. Esto indica si la solicitud llegó a Authentik.

Los fallos que encontrará realmente

Bucle de redirección infinito entre la aplicación y la página de inicio de sesión. El host externo del proveedor no coincide con el que usa el navegador. Normalmente, http:// en el proveedor no coincide con https:// en la barra de direcciones. La cookie de sesión se establece entonces para un origen diferente. Por eso, cada retorno parece una nueva solicitud anónima. Corrija el host externo y borre las cookies de ambos dominios antes de volver a probar.

404 en /outpost.goauthentik.io/start. Falta el router de outpost o su prioridad es inferior a la del router general para ese host.

La aplicación carga sin solicitar un inicio de sesión. La etiqueta middlewares hace referencia a un middleware que no existe. Traefik no muestra ninguna advertencia en este caso. Por tanto, un error tipográfico en authentik@docker simplemente hace que no se ejecute ningún middleware. Abra el dashboard de Traefik y confirme que el router muestra el middleware.

403 de Authentik después de un inicio de sesión correcto. El usuario está autenticado, pero no autorizado. La aplicación tiene una vinculación de política o un requisito de grupo que este usuario no cumple. El registro Events de la interfaz de administración indica qué política denegó el acceso.

Cuándo Keycloak encaja mejor

Keycloak es el proyecto más antiguo, respaldado por Red Hat, y es la opción más sólida para la gestión clásica de identidades empresariales: federación SAML intensiva, intermediación de inicios de sesión desde varios proveedores de identidad externos al mismo tiempo, y exportación e importación de realms como ruta de migración documentada. Para algunas organizaciones, el soporte comercial que lo respalda también es importante sobre el papel. La desventaja es que Keycloak no incluye su propio proxy. Por tanto, proteger una aplicación que no admite OIDC (OpenID Connect) requiere ejecutar algo como oauth2-proxy junto a él. El proveedor de proxy integrado de Authentik ya ofrece esa función. Por eso, la mayoría de los administradores que alojan sus propios servicios y tienen un conjunto mixto de aplicaciones termina eligiendo Authentik.

Copias de seguridad y actualizaciones

Tres elementos permiten realizar una restauración: la base de datos de PostgreSQL, el directorio ./data y .env.

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

Guarde ese volcado junto con .env. El volcado por sí solo no es suficiente, porque la clave secreta que protege los datos de sesión y de tokens se encuentra en .env.

Las actualizaciones consisten en cambiar una etiqueta. Establezca AUTHENTIK_TAG en .env con la versión que desea y, a continuación, ejecute docker compose pull seguido de docker compose up -d. Lea primero las notas de la versión, porque Authentik usa versiones basadas en fechas y algunas versiones incluyen migraciones que requieren llegar desde la versión anterior. Cree el volcado de la base de datos antes de ejecutar pull, no después.

FAQ

¿Authentik es gratuito para alojarlo por cuenta propia?

La edición de código abierto es gratuita e incluye todo lo anterior: el proveedor de proxy, la autenticación delegada, OIDC (OpenID Connect), SAML y el motor de flujos. Un nivel empresarial de pago añade soporte y algunas funciones empresariales, pero nada de lo descrito aquí requiere una licencia.

¿Necesito Traefik para usar Authentik?

No. La autenticación delegada funciona con nginx mediante auth_request y con Caddy mediante forward_auth. El patrón es el mismo en todos los casos: el proxy inverso consulta Authentik para cada solicitud, y el prefijo de ruta /outpost.goauthentik.io/ del hostname protegido debe dirigir las solicitudes a Authentik en lugar de a la aplicación.

¿Por qué mi aplicación protegida alterna indefinidamente entre el inicio de sesión y el error?

El host externo configurado en el proveedor de proxy no coincide con la URL que usa el navegador, normalmente http frente a https. La cookie de sesión se emite para un origen y se lee desde otro, por lo que Authentik recibe una solicitud anónima cada vez. Corrija el host externo y elimine las cookies de ambos hostnames antes de volver a probar.

¿Cuánta RAM necesita Authentik?

El mínimo documentado es de 2 núcleos de CPU y 2 GB de RAM a fecha de julio de 2026. Esta cantidad cubre PostgreSQL, el servidor y el worker conjuntamente. En un equipo con 2 GB, el worker es el primer proceso que el kernel termina cuando falta memoria. El síntoma es que las tareas en segundo plano y el correo saliente dejan de funcionar, mientras la página de inicio de sesión sigue funcionando. Asigne 4 GB si el mismo servidor también ejecuta las aplicaciones que está protegiendo.