Authentik en profundidad

En el capítulo anterior montaste Authelia. Un guardián eficaz, ligero, configurable con YAML. Funciona. Pero llega un momento en que necesitas más. Necesitas que un usuario pueda iniciar sesión con su cuenta de Google. O necesitas conectar una aplicación que solo habla SAML. O quieres que los usuarios gestionen sus propias contraseñas desde un panel web. O necesitas un directorio LDAP para tu VPN. Authelia no puede con todo eso. Y no es culpa suya. Authelia es un guardián de entrada, no un proveedor de identidad completo. Aquí entra Authentik.

Authentik es un IdP (Identity Provider) completo. Piensa en Okta, Keycloak o Azure AD, pero open source y autoalojado. No solo protege tus aplicaciones con forward-auth. También emite tokens OIDC y OAuth2, expone un directorio LDAP, soporta SAML, tiene un catálogo de aplicaciones con SSO, y te deja construir flujos de autenticación personalizados desde una interfaz web.

¿Y por qué deberías plantearte Authentik si ya tienes Authelia funcionando? Porque son herramientas diferentes. Authelia es un cortafuegos de autenticación. Authentik es una plataforma de identidad. Cada una tiene su sitio, y en este capítulo vas a ver cuál es el tuyo.

Vamos a instalar Authentik desde cero con Docker Compose y Traefik, configurar los primeros flujos, conectar aplicaciones con OIDC, montar un proxy forward-auth, y compararlo con Authelia para que sepas cuándo usar cada uno.

Instalación con Docker Compose y Traefik

Authentik no es un solo contenedor. Es un ecosistema. Necesitas cuatro servicios: el servidor web, el worker de tareas en segundo plano, PostgreSQL para los datos y Redis para la caché y las sesiones.

server y worker

Authentik separa la interfaz web (server) del procesamiento en segundo plano (worker). El worker se encarga de tareas pesadas: enviar correos, sincronizar directorios, procesar eventos. Usan la misma imagen, pero el worker arranca con el comando worker.

Estructura de directorios

/home/lorenzo/docker/authentik/
├── docker-compose.yml
├── .env
├── certs/
├── media/
└── custom-templates/

Creas la estructura con:

mkdir -p /home/lorenzo/docker/authentik/{certs,media,custom-templates}
cd /home/lorenzo/docker/authentik

El archivo .env

Authentik se configura casi todo con variables de entorno. No hay un archivo configuration.yml monolítico como en Authelia. Creas un .env con los valores sensibles:

# Contraseñas y secretos
PG_PASS=$(openssl rand -base64 36 | tr -d '\n')
AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')
AUTHENTIK_BOOTSTRAP_TOKEN=$(openssl rand -base64 36 | tr -d '\n')
AUTHENTIK_BOOTSTRAP_EMAIL=admin@tudominio.com
AUTHENTIK_BOOTSTRAP_PASSWORD=UnaContraseñaSegura

Y lo guardas en .env:

cat > .env << EOF
PG_PASS=$PG_PASS
AUTHENTIK_SECRET_KEY=$AUTHENTIK_SECRET_KEY
AUTHENTIK_BOOTSTRAP_TOKEN=$AUTHENTIK_BOOTSTRAP_TOKEN
AUTHENTIK_BOOTSTRAP_EMAIL=admin@tudominio.com
AUTHENTIK_BOOTSTRAP_PASSWORD=UnaContraseñaSegura
AUTHENTIK_BOOTSTRAP_USERNAME=admin
AUTHENTIK_LOG_LEVEL=info
AUTHENTIK_REDIS__HOST=redis
AUTHENTIK_POSTGRESQL__HOST=postgresql
AUTHENTIK_POSTGRESQL__NAME=authentik
AUTHENTIK_POSTGRESQL__USER=authentik
AUTHENTIK_POSTGRESQL__PASSWORD=${PG_PASS}
EOF

Las variables con __ (doble guion bajo) son intencionadas. Authentik las usa como separador jerárquico. AUTHENTIK_POSTGRESQL__HOST se traduce en authentik.postgresql.host en la configuración interna.

docker-compose.yml

services:
  postgresql:
    image: docker.io/library/postgres:16-alpine
    container_name: authentik-postgres
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 5s
    volumes:
      - ./database:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${PG_PASS}
      POSTGRES_USER: authentik
      POSTGRES_DB: authentik
    env_file:
      - .env
    networks:
      - traefik

  redis:
    image: docker.io/library/redis:alpine
    container_name: authentik-redis
    restart: unless-stopped
    command: --save 60 1 --loglevel warning
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    volumes:
      - ./redis:/data
    networks:
      - traefik

  server:
    image: ghcr.io/goauthentik/server:latest
    container_name: authentik-server
    restart: unless-stopped
    ports:
      - "9000:9000"
      - "9443:9443"
    volumes:
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    env_file:
      - .env
    environment:
      AUTHENTIK_LOG_LEVEL: info
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - traefik
    labels:
      # Router principal para el admin de Authentik
      - "traefik.enable=true"
      - "traefik.http.routers.authentik.rule=Host(`auth.tudominio.com`)"
      - "traefik.http.routers.authentik.entrypoints=websecure"
      - "traefik.http.routers.authentik.tls=true"
      - "traefik.http.routers.authentik.tls.certresolver=letsencrypt"
      - "traefik.http.services.authentik.loadbalancer.server.port=9000"

  worker:
    image: ghcr.io/goauthentik/server:latest
    container_name: authentik-worker
    restart: unless-stopped
    command: worker
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    env_file:
      - .env
    environment:
      AUTHENTIK_LOG_LEVEL: info
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - traefik

networks:
  traefik:
    external: true

Fíjate en el worker. Monta el socket de Docker (/var/run/docker.sock). Esto es necesario para que Authentik pueda gestionar outposts automáticamente. Los outposts son los componentes que despliega Authentik para conectar aplicaciones. Lo veremos en detalle más adelante.

Si no te sientes cómodo montando el socket de Docker en un contenedor (comprensible), puedes ejecutar los outposts de forma manual o usar el outpost embebido que corre dentro del propio servidor.

Arranque inicial

docker compose up -d

El primer arranque tarda un poco. Authentik tiene que inicializar la base de datos, ejecutar migraciones, crear el usuario administrador que definiste en .env. Puedes seguir los logs con:

docker compose logs -f server

Cuando veas algo como:

authentik-server  | [INFO] authentik.tenants: Listening on: http://0.0.0.0:9000

Authentik está listo. Abre https://auth.tudominio.com en tu navegador.

Primer inicio de sesión

Usas el usuario y contraseña que definiste en .env (por defecto admin y la contraseña que pusiste en AUTHENTIK_BOOTSTRAP_PASSWORD). Nada más entrar, Authentik te pide que configures el primer flujo de autenticación. Te guía con un asistente.

Pero no te dejes engañar por la interfaz bonita. Authentik es profundo. Muy profundo. Vamos a verlo por partes.

La diferencia fundamental con Authelia

Antes de continuar, necesitas tener clara la diferencia entre Authentik y Authelia. No es que uno sea mejor que el otro. Es que resuelven problemas distintos.

Authelia es un forward-auth gateway. Se sienta detrás de tu proxy inverso y decide, petición a petición, si el usuario está autenticado. Su modelo es simple: el proxy le pregunta «¿este usuario puede pasar?», y Authelia responde sí o no. No emite tokens OIDC. No expone un directorio LDAP. No tiene un catálogo de aplicaciones. Todo se configura en YAML.

Authentik es un proveedor de identidad (IdP). Puede hacer forward-auth, sí, pero también mucho más. Tus aplicaciones pueden hablar directamente con Authentik usando OIDC, OAuth2, SAML o LDAP. Los usuarios tienen un panel donde ven todas las aplicaciones a las que tienen acceso. Los flujos de autenticación son personalizables desde una interfaz web. Puedes tener múltiples fuentes de usuarios (base de datos local, LDAP externo, Google, GitHub, Azure AD).

La metáfora: Authelia es el portero de un edificio que solo deja entrar a los que están en la lista. Authentik es la oficina de identidad que emite carnés, gestiona accesos, se integra con otras organizaciones y tiene un mostrador de atención al usuario.

¿Cuándo usar cada uno? Lo vemos al final del capítulo con una tabla comparativa. Pero adelanto: si solo necesitas proteger 5-10 servicios con 2FA y no quieres complicarte, Authelia. Si necesitas SSO real, integración con servicios externos, múltiples protocolos o gestión de usuarios desde un panel, Authentik.

Flujos de autenticación personalizables

Aquí está el corazón de Authentik. Y donde más se diferencia de Authelia.

El modelo: flows, stages, policies, binds

Authelia tiene cuatro políticas fijas (bypass, one_factor, two_factor, deny). Authentik tiene un sistema de flujos completamente dinámico.

Flow: una secuencia completa de autenticación. Por ejemplo, «Inicio de sesión», «Registro de usuario», «Recuperación de contraseña», «Configuración de 2FA».
Stage: un paso dentro de un flujo. Por ejemplo, «Identificación con usuario y contraseña», «Verificación TOTP», «Aceptación de términos».
Policy: una regla que decide si un stage se ejecuta o no. Por ejemplo, «Solo mostrar TOTP si el usuario ha configurado 2FA».
Binding: la conexión entre un stage y un flow, incluyendo la política que lo gobierna.

Puedes construir flujos tan complejos como quieras. ¿Necesitas que los usuarios de un grupo concreto pasen por un segundo factor adicional si se conectan desde fuera de Europa? Lo construyes con stages y policies.

Flujo por defecto

Cuando instalas Authentik por primera vez, ya vienen creados varios flujos por defecto:

default-authentication-flow: el login estándar (usuario + contraseña + 2FA si aplica).
default-invalidation-flow: cierre de sesión.
default-enrollment-flow: auto-registro de nuevos usuarios.
default-password-change-flow: cambio de contraseña.

Puedes modificarlos, clonarlos o crear nuevos desde cero.

Crear un stage personalizado

Vamos a crear un stage que solicite un campo adicional, como un código de empleado, antes de permitir el acceso a una aplicación sensible.

Desde el panel de administración, vas a Flows > Stages y creas un nuevo Prompt Stage. Añades un campo de texto:

Field key: employee_code
Label: «Código de empleado»
Type: Text
Required: sí

Luego creas un User Write Stage para guardar ese valor en el perfil del usuario.

Después, enlazas ese stage al flujo de autenticación con un binding. El resultado: cuando un usuario inicia sesión, después de poner su contraseña, Authentik le pide el código de empleado.

Policies condicionales

Las policies son expresiones que se evalúan en tiempo real. Puedes usar:

Expression Policy: escribes una expresión Python. Si devuelve True, la política se cumple.
Password Policy: fuerza requisitos de complejidad.
User Login Stage Policy: controla cuándo se muestra un stage.
GeoIP Policy: basada en ubicación geográfica.

Un ejemplo: una expression policy que solo permite acceso en horario laboral:

from datetime import datetime
from django.utils import timezone

now = timezone.localtime(timezone.now())
return 9 <= now.hour < 18 and now.weekday() < 5

Si devuelve True, el usuario puede continuar. Si devuelve False, el flujo se interrumpe o redirige a otro stage.

Bindings con orden

Los bindings tienen un orden numérico. Authentik evalúa los stages en ese orden. Puedes tener:

Binding 1: Stage de usuario/contraseña (sin política, siempre se ejecuta).
Binding 2: Stage de TOTP (solo si policy «usuario_tiene_totp» devuelve True).
Binding 3: Stage de aceptación de términos (solo si policy «usuario_nuevo» devuelve True).

Si una policy falla, Authentik salta ese stage y sigue con el siguiente. Si todas fallan, el flujo termina, y el usuario no se autentica.

Esto te da un control milimétrico sobre la experiencia de inicio de sesión.

Integración con Traefik: forward-auth de Authentik

Authentik puede proteger aplicaciones de dos formas: mediante forward-auth (como Authelia) o mediante SSO con OIDC/OAuth2.

Empecemos por forward-auth, que es la que ya conoces del capítulo anterior.

El middleware authentik_proxy

Authentik despliega un proxy outpost que actúa como intermediario. Cuando Traefik envía una petición de forward-auth al outpost, este comprueba si el usuario tiene sesión. Si no la tiene, redirige al login de Authentik. Si la tiene, deja pasar la petición.

Tienes dos modalidades de forward-auth:

Single-application mode: cada aplicación protegida necesita un proxy provider y un outpost dedicados. El outpost se despliega como un contenedor independiente.

Domain-level mode: un solo outpost protege todo un dominio. Es más sencillo y es el que vas a usar si tienes varias aplicaciones en subdominios.

Crear un proxy provider en Authentik

Desde el panel de administración:

Vas a Applications > Providers y pulsas Create.
Seleccionas Proxy Provider.
Name: proxy-miservicio
Authorization flow: default-authentication-flow (o uno personalizado).
Mode: Forward auth (single application).
External host: https://app.tudominio.com.

Una vez creado el provider, creas una Application que lo use:

Vas a Applications > Applications y pulsas Create.
Name: Mi Servicio
Slug: mi-servicio
Provider: seleccionas proxy-miservicio.

Configurar el middleware en Traefik

Para forward-auth single-application, necesitas que Authentik despliegue un outpost. Si usas el outpost embebido (el que corre dentro del servidor), el endpoint de forward-auth está en:

http://authentik-server:9000/outpost.goauthentik.io/auth/traefik

Pero lo normal es crear un outpost gestionado. Authentik se encarga de desplegar el contenedor del outpost automáticamente, siempre que el worker tenga acceso al socket de Docker.

El middleware en Traefik se configura así (archivo dinámico):

# /home/lorenzo/docker/traefik/rules/authentik-middleware.yml
http:
  middlewares:
    authentik-auth:
      forwardAuth:
        address: "http://authentik-proxy:9000/outpost.goauthentik.io/auth/traefik"
        trustForwardHeader: true
        authResponseHeaders:
          X-authentik-username: username
          X-authentik-groups: groups
          X-authentik-email: email
          X-authentik-name: name
          X-authentik-uid: uid

La dirección http://authentik-proxy:9000 apunta al contenedor del outpost. Si usas el outpost embebido, apunta a http://authentik-server:9000.

Luego proteges un servicio añadiendo el middleware:

labels:
  - "traefik.http.routers.mi-servicio.middlewares=authentik-auth@file"

Domain-level forward auth

Si tienes muchas aplicaciones, el domain-level es más práctico. Configuras el provider en modo Forward auth (domain level) con un dominio como *.tudominio.com. El middleware de Traefik se configura igual, pero el outpost responde para cualquier subdominio que tenga una aplicación configurada en Authentik.

La ventaja: no necesitas crear un provider por cada aplicación. Creas las aplicaciones en Authentik, las asocias a un dominio, y el outpost resuelve automáticamente a qué aplicación debe redirigir.

Routing de /outpost.goauthentik.io

Hay un detalle importante. El outpost necesita que las rutas /outpost.goauthentik.io/ sean accesibles sin autenticación. Si proteges todo el dominio con el middleware forward-auth, el propio outpost quedaría bloqueado.

La solución es añadir una excepción en las reglas de Traefik:

labels:
  # Router para el outpost (sin autenticación)
  - "traefik.http.routers.authentik-outpost.rule=Host(`app.tudominio.com`) && PathPrefix(`/outpost.goauthentik.io`)"
  - "traefik.http.routers.authentik-outpost.entrypoints=websecure"
  - "traefik.http.routers.authentik-outpost.tls=true"

  # Router para la app (con autenticación)
  - "traefik.http.routers.mi-servicio.rule=Host(`app.tudominio.com`)"
  - "traefik.http.routers.mi-servicio.entrypoints=websecure"
  - "traefik.http.routers.mi-servicio.tls=true"
  - "traefik.http.routers.mi-servicio.middlewares=authentik-auth@file"

Como las reglas se evalúan por orden de especificidad, el router del outpost (con PathPrefix) coincide primero y no aplica el middleware de autenticación.

Catálogo de aplicaciones: outposts, proveedores OIDC/OAuth2/SAML/LDAP

Authentik no solo protege aplicaciones con forward-auth. También actúa como proveedor de identidad para aplicaciones que soportan protocolos estándar.

Proveedores OIDC y OAuth2

Si tu aplicación soporta OpenID Connect (como Grafana, Nextcloud, GitLab o Vaultwarden), puedes configurarla para que delegue la autenticación en Authentik.

Desde el panel, creas un OAuth2/OpenID Provider:

Name: oidc-grafana
Authentication flow: default-authentication-flow
Client ID: lo genera Authentik automáticamente.
Client Secret: lo genera Authentik.
Redirect URIs: https://grafana.tudominio.com/login/generic_oauth.

Luego en Grafana configuras:

[auth.generic_oauth]
enabled = true
name = Authentik
client_id = <client-id-de-authentik>
client_secret = <client-secret>
auth_url = https://auth.tudominio.com/application/o/authorize/
token_url = https://auth.tudominio.com/application/o/token/
api_url = https://auth.tudominio.com/application/o/userinfo/
scopes = openid email profile

Y cuando un usuario entra en Grafana, ve el botón «Iniciar sesión con Authentik». Pulsa, se autentica en Authentik (con 2FA si aplica), y vuelve a Grafana con la sesión iniciada.

Eso es SSO real. No un proxy que intercepta peticiones, sino una integración directa entre la aplicación y el proveedor de identidad.

Proveedor SAML

Para aplicaciones que solo hablan SAML (como algunas herramientas empresariales o portales gubernamentales), Authentik también sirve:

Creas un SAML Provider en Authentik.
Descargas el metadata XML desde https://auth.tudominio.com/api/v3/providers/saml/<id>/metadata/.
Lo importas en la aplicación que consume SAML.

Proveedor LDAP

Aquí Authentik hace algo que Authelia no puede ni soñar: exponer un directorio LDAP.

¿Por qué es útil? Porque muchas aplicaciones y servicios esperan un directorio LDAP: VPNs (OpenVPN, WireGuard con autenticación LDAP), sistemas de archivos, clientes de correo, herramientas de administración.

Configuras un LDAP Provider en Authentik con el tipo Outpost. Authentik despliega un contenedor que expone los puertos 389 (LDAP) y 636 (LDAPS). Las aplicaciones se conectan a ese outpost como si fuera un Active Directory o un OpenLDAP.

# Ejemplo de conexión desde cualquier cliente LDAP
ldapsearch -H ldap://authentik-ldap:389 \
  -D "cn=admin,dc=tudominio,dc=com" \
  -w "contraseña" \
  -b "dc=tudominio,dc=com"

Outposts: los conectores

Los outposts son los componentes que despliega Authentik para conectar con el mundo exterior. Cada tipo de outpost despliega un servicio diferente:

Proxy Outpost: para forward-auth con Traefik, nginx, Caddy, etc.
LDAP Outpost: expone el directorio LDAP.
RADIUS Outpost: para autenticación RADIUS (VPNs, WiFi empresarial).

Los outposts pueden ser gestionados (Authentik los despliega automáticamente) o manuales (los configuras tú). La opción gestionada es más cómoda, pero requiere montar el socket de Docker en el worker.

Gestión de usuarios y grupos

Authentik tiene un sistema completo de gestión de usuarios con interfaz web. No necesitas editar archivos YAML a mano. Desde el panel puedes crear, modificar, deshabilitar y borrar usuarios. También puedes asignar grupos, definir atributos personalizados y ver el historial de actividad.

Creación de usuarios desde el panel

Vas a Directory > Users y pulsas Create. Rellenas:

Username: nombre de usuario.
Name: nombre mostrado.
Email: obligatorio para recuperación y notificaciones.
Groups: grupos a los que pertenece.
Attributes: pares clave/valor para atributos personalizados.

Sincronización con LDAP externo

Si ya tienes un directorio LDAP (OpenLDAP, FreeIPA, Active Directory), Authentik puede sincronizar usuarios y grupos automáticamente.

Configuras un LDAP Source:

Vas a Directory > Federation & Sources y creas un LDAP Source.
Server URI: ldap://tu-servidor-ldap:389.
Bind DN: cn=admin,dc=ejemplo,dc=com.
Bind Password: la contraseña del bind.
Base DN: dc=ejemplo,dc=com.
User object filter: (objectClass=person).
Group object filter: (objectClass=groupOfNames).

Authentik sincroniza los usuarios periódicamente. Puedes forzar una sincronización manual desde el mismo panel.

¿Qué pasa si un usuario se deshabilita en el LDAP origen? Authentik lo detecta en la siguiente sincronización y lo deshabilita también. Los cambios en grupos se reflejan igual.

Fuentes de identidad externas

Además de LDAP, Authentik puede usar:

Google Workspace: sincroniza usuarios desde Google.
Microsoft Azure AD: sincroniza desde Azure.
OpenID Connect: usa otro IdP como fuente (por ejemplo, que Authentik confíe en Keycloak).
SCIM: protocolo estándar para sincronización de identidades. Si tu HRM o sistema de gestión de personal soporta SCIM, Authentik puede recibir los cambios en tiempo real.

SCIM (System for Cross-domain Identity Management)

SCIM es el estándar moderno para sincronización de identidades. Authentik puede actuar como proveedor SCIM (empuja usuarios a otros sistemas) o como consumidor SCIM (recibe usuarios de otros sistemas).

Como consumidor, configuras un SCIM Source con el endpoint y el token. Cuando el sistema origen crea, modifica o elimina un usuario, envía el cambio a Authentik y este lo aplica automáticamente.

Esto es útil si usas un directorio corporativo y quieres que Authentik refleje los mismos usuarios sin intervención manual.

Grupos y herencia

Los grupos en Authentik pueden anidarse. Un grupo puede ser miembro de otro grupo. Los permisos y accesos se heredan.

Por ejemplo:

Grupo desarrollo es miembro de ingenieria.
Grupo ingenieria tiene acceso a la aplicación gitlab.
Todos los usuarios de desarrollo heredan el acceso a gitlab.

Esto simplifica la gestión cuando tienes muchos grupos y muchas aplicaciones.

2FA: múltiples opciones

Authentik soporta varios métodos de segundo factor. Y a diferencia de Authelia, puedes tener varios activos a la vez y el usuario elige cuál usar en cada inicio de sesión.

TOTP

El clásico. Códigos de 6 dígitos que cambian cada 30 segundos. Compatible con Google Authenticator, Aegis, 2FAS, Authy.

Desde el panel de administración, configuras:

authentik_stages_authenticator_totp:
  digits: 6
  period: 30

El usuario registra su dispositivo desde su panel de usuario, escaneando un código QR.

WebAuthn (FIDO2)

Llaves de seguridad físicas (YubiKey, SoloKey) o biometría del dispositivo (huella, Face ID). Es el método más seguro porque es resistente a phishing.

El stage de WebAuthn se configura con:

Device type restrictions: qué tipos de dispositivos aceptas (cross-platform para llaves USB, platform para biometría del dispositivo).
Resident key requirement: si la llave debe almacenar la credencial (discoverable credential).
User verification: si requiere PIN o huella.

SMS y Email

Authentik puede enviar códigos por SMS o email como segundo factor. No es lo más seguro (SMS es interceptable), pero es mejor que nada y útil para usuarios que no tienen smartphone.

Para SMS necesitas un proveedor como Twilio. Configuras el stage SMS Authenticator con las credenciales de Twilio.

Para email, Authentik usa el mismo sistema de correo configurado globalmente. El stage Email Authenticator envía un código de 6 dígitos al correo del usuario.

Códigos de respaldo (Backup codes)

Como en Authelia, Authentik genera códigos de un solo uso. El usuario los genera desde su panel y los guarda en un lugar seguro. Cada código solo vale para una autenticación.

Puedes configurar cuántos códigos se generan y su longitud:

authentik_stages_authenticator_backup:
  number: 12
  length: 8

Duo Push

Authentik se integra con Duo Security. Si ya usas Duo en tu organización, puedes añadirlo como segundo factor. El usuario recibe una notificación push en su móvil y la aprueba.

Varios factores simultáneos

El usuario puede tener TOTP, WebAuthn y códigos de respaldo configurados a la vez. Cuando inicia sesión y el flujo llega al stage de 2FA, Authentik le muestra los métodos disponibles. Elige el que prefiera.

Diferencias clave con Authelia: cuándo elegir uno u otro

Llegamos a la pregunta del millón: ¿Authelia o Authentik?

La respuesta corta: depende de lo que necesites.

Tabla comparativa

Authelia:

Propósito: forward-auth gateway ligero.
Configuración: archivos YAML.
Recursos: ~100 MB RAM, binario Go de 26 MB.
Protocolos: forward-auth, OIDC básico (como proveedor).
Gestión usuarios: archivo YAML.
Flujos autenticación: 4 políticas fijas.
2FA: TOTP, WebAuthn, códigos respaldo.
Panel usuario: mínimo (solo configurar 2FA).
LDAP: como fuente de usuarios, no como proveedor.
SAML: no.
Outposts: no aplica.
Curva aprendizaje: baja-media.
Ideal para: homelab pequeño, <10 servicios, sin necesidad de SSO real.

Authentik:

Propósito: IdP completo.
Configuración: interfaz web + variables de entorno.
Recursos: ~1-2 GB RAM (server + worker + PostgreSQL + Redis).
Protocolos: forward-auth, OIDC, OAuth2, SAML, LDAP, RADIUS.
Gestión usuarios: panel web, LDAP, SCIM, Google, Azure AD.
Flujos autenticación: completamente personalizables (flows + stages + policies).
2FA: TOTP, WebAuthn, SMS, email, Duo, códigos respaldo.
Panel usuario: completo (aplicaciones, 2FA, perfil, actividad).
LDAP: como fuente y como proveedor.
SAML: sí.
Outposts: proxy, LDAP, RADIUS.
Curva aprendizaje: media-alta.
Ideal para: múltiples servicios, SSO real, equipos, integración corporativa.

¿Cuándo elegir Authelia?

Elige Authelia cuando:

Tienes menos de 10 servicios que proteger.
No necesitas SSO real (que las aplicaciones hablen OIDC directamente).
Solo necesitas forward-auth con 2FA.
Tu servidor tiene recursos limitados (menos de 2 GB RAM).
Prefieres configuración en archivos a interfaz web.
No necesitas LDAP, SAML ni integración con directorios externos.
Quieres algo que funcione en 15 minutos y no volver a tocarlo.

¿Cuándo elegir Authentik?

Elige Authentik cuando:

Tienes más de 10 servicios y quieres un catálogo centralizado.
Necesitas SSO real con OIDC para aplicaciones como Grafana, Nextcloud, GitLab.
Tus aplicaciones requieren SAML.
Quieres exponer un directorio LDAP para VPN u otros servicios.
Necesitas que los usuarios gestionen su perfil y 2FA desde un panel.
Tienes integración con directorios externos (Active Directory, FreeIPA).
Quieres flujos de autenticación personalizados con políticas condicionales.
Gestionas un equipo o una organización, no solo tu homelab personal.

Y si uso los dos?

Hay quien pone Authelia como gateway de forward-auth para servicios ligeros y Authentik como IdP para SSO real. No es lo más común, pero funciona. Cada uno en su capa.

Personalmente, creo que Authentik puede hacer todo lo que hace Authelia y mucho más. El precio es la complejidad y los recursos. Si tienes RAM suficiente y ganas de aprender, Authentik es la opción más potente.

Verificación: probar el flujo completo

Has instalado Authentik, configurado un proxy provider, conectado Traefik. Ahora toca verificar que todo funciona.

Probar el portal de administración

Abre https://auth.tudominio.com. Deberías ver la pantalla de login de Authentik, no la de Authelia. Inicia sesión con el usuario administrador. Verifica que puedes:

Ver el panel de administración.
Navegar a Directory > Users y ver los usuarios.
Navegar a Applications > Applications y ver las aplicaciones configuradas.

Probar una aplicación protegida con forward-auth

Abre https://app.tudominio.com (una aplicación que hayas protegido con el middleware). Si no tienes sesión en Authentik, deberías ser redirigido al login. Inicia sesión. Después del login, vuelves a la aplicación.

Probar SSO con OIDC

Si has configurado una aplicación con OIDC (por ejemplo, Grafana), abre su URL. Deberías ver el botón «Iniciar sesión con Authentik». Púlsalo. Te redirige a Authentik, inicias sesión (con 2FA si aplica), y vuelves a la aplicación autenticado.

Ver logs de autenticación

Authentik registra cada evento de autenticación. Puedes verlos desde el panel de administración en Events > Logs.

Cada entrada muestra:

User: quién inició sesión.
Action: login, logout, failed attempt, 2FA setup.
Context: desde qué IP, qué navegador, qué aplicación.
Timestamp: cuándo ocurrió.

Si algo falla, los logs son tu mejor aliado. Busca errores como invalid_password, expired_session o invalid_redirect_uri.

Probar los logs del outpost

Si usas forward-auth, el outpost tiene sus propios logs. Puedes verlos con:

docker compose logs -f <nombre-del-outpost>

O, si usas el outpost embebido:

docker compose logs -f server | grep outpost

Busca líneas como [DEBUG] [outpost] Handling forward auth request for <url>.

Health check

Authentik expone un endpoint de salud en:

https://auth.tudominio.com/-/health/

Si devuelve 200 OK y un JSON con {"status": "healthy"}, Authentik está vivo y coleando.

También puedes verificar los componentes individuales:

# Verificar que PostgreSQL responde
docker compose exec postgresql pg_isready

# Verificar que Redis responde
docker compose exec redis redis-cli ping

# Verificar que el worker está procesando tareas
docker compose exec worker celery -A authentik.root.celery inspect active

Resumen

Authentik no es solo un sustituto de Authelia. Es una plataforma de identidad completa que cambia la forma de gestionar la autenticación en tu infraestructura.

En este capítulo has visto:

La instalación completa con Docker Compose, separando server y worker, con PostgreSQL y Redis.
La diferencia fundamental con Authelia: Authentik es un IdP, no solo un forward-auth gateway.
El sistema de flujos, stages, policies y binds para personalizar cada paso de la autenticación.
La integración con Traefik mediante el middleware forward-auth del outpost proxy.
Los tipos de proveedores: OIDC, OAuth2, SAML y LDAP, cada uno para un tipo de aplicación.
La gestión de usuarios desde el panel web, con sincronización LDAP y SCIM.
Las múltiples opciones de 2FA: TOTP, WebAuthn, SMS, email, Duo, códigos de respaldo.
Las diferencias clave con Authelia y cuándo elegir uno u otro.
Cómo verificar que todo funciona: logs, health check, pruebas de flujo completo.

¿Es Authentik más complejo que Authelia? Sí. ¿Requiere más recursos? También. Pero la flexibilidad que ganas es enorme. Cuando llegue el día en que necesites conectar una aplicación que solo habla SAML, o sincronizar usuarios con Active Directory, o crear un flujo de autenticación con políticas condicionales, Authentik estará ahí para hacerlo posible.

Más información