Por qué centralizar la autenticación en su VPS
Cuando acumula herramientas autoalojadas (Grafana, Nextcloud, Gitea, un dashboard interno), cada una aporta su propia base de usuarios y su propia política de contraseñas. Es una pesadilla de mantener y una superficie de ataque multiplicada. Authentik lo resuelve haciendo de proveedor de identidad (IdP): admite OAuth2/OIDC, SAML, LDAP y, sobre todo, el forward auth, que permite proteger cualquier aplicación detrás de un reverse proxy, incluso aquellas sin ninguna noción de login. El autoalojamiento en un VPS garantiza que sus credenciales nunca pasen por un servicio de terceros y que usted siga siendo dueño del árbol de usuarios y de las políticas de MFA.
Lo que gana con Authentik
- Un solo juego de credenciales para todas sus aplicaciones, con cierre de sesión centralizado.
- MFA (TOTP, WebAuthn/llaves FIDO2, códigos de respaldo) aplicado de manera uniforme por política.
- El forward auth para proteger aplicaciones «sin login», imposible con un IdP clásico.
- Flows totalmente personalizables (registro, recuperación, captcha, condiciones de acceso).
- Conectores OAuth2/OIDC, SAML y LDAP para conectar tanto aplicaciones modernas como legacy.
- Aprovisionamiento y revocación de accesos inmediatos cuando se marcha un colaborador.
Requisitos para este despliegue
Authentik es más exigente que un simple servicio: la stack incluye el servidor, un worker, PostgreSQL y Redis. Cuente con un VPS de al menos 2 vCPU y 4 GB de RAM para un funcionamiento cómodo; 2 GB son un mínimo estricto que puede sufrir bajo carga. Se requieren Docker y Docker Compose, así como un nombre de dominio dedicado (auth.midominio.com) con un registro A. Un reverse proxy (Traefik, Nginx Proxy Manager o Caddy) es indispensable para gestionar el SSL y el forward auth hacia sus demás aplicaciones.
Desplegar Authentik con Docker Compose
Obtener el compose oficial y generar los secretos
Descargue el
docker-compose.ymlde referencia de Authentik. Genere los valores sensibles en un archivo.env:PG_PASSyAUTHENTIK_SECRET_KEYconopenssl rand -base64 60. No reutilice nunca una clave de ejemplo.Arrancar la stack
Lance
docker compose up -d. Se levantan cuatro contenedores:server,worker,postgresqlyredis. Vigile la inicialización condocker compose logs -f serverhasta ver el servidor listo para escuchar.Finalizar la instalación en /if/flow/initial-setup/
En el primer arranque, vaya a
https://auth.midominio.com/if/flow/initial-setup/para definir la contraseña de la cuentaakadmin. Es su superadministrador: protéjalo de inmediato con MFA.Configurar el reverse proxy y el SSL
Enrute
auth.midominio.comhacia el puerto9000(HTTP) o9443(HTTPS) del contenedor server a través de su reverse proxy, con un certificado Let's Encrypt. Authentik debe servirse obligatoriamente por HTTPS para que las cookies de sesión y WebAuthn funcionen.Crear un provider y una aplicación
En la administración, cree un Provider (OIDC para una aplicación moderna, o Proxy para el forward auth) y luego la Application asociada. Para OIDC, recupere el
client_id/client_secrety la URL.well-known/openid-configurationpara pegarlos en la aplicación cliente.Proteger una aplicación con forward auth
Para una aplicación sin login nativo, cree un Proxy Provider y declare un middleware de autenticación en su reverse proxy que apunte al endpoint
/outpost.goauthentik.io/auth/. Toda petición no autenticada se redirige entonces a Authentik antes de llegar a la aplicación.
Active un Outpost integrado y aproveche los «property mappings» para inyectar cabeceras (X-authentik-username, X-authentik-groups) hacia sus aplicaciones en forward auth: muchas aplicaciones (Grafana, por ejemplo) saben leer esas cabeceras para autoaprovisionar usuarios y asignar roles. Obtiene así no solo SSO, sino también un mapeo de grupos a roles totalmente automatizado, sin configuración manual en cada herramienta.
