Authentik verrouille tous vos services self-hostés derrière un mot de passe unique
Authentik s’impose en 2026 comme le fournisseur d’identité de référence pour le self-hosting, devant Authelia et Keycloak. Un Docker Compose, cinq minutes de configuration, et tous vos services partagent le même login, la même MFA et le même annuaire.
Le 19 juin 2026, Authentik cumule plus de 15 000 étoiles GitHub et une communauté qui double chaque année. Il y a trois ans, le projet était encore un outsider face à Keycloak et Authelia. Aujourd’hui, c’est le fournisseur d’identité que la communauté self-hosted recommande par défaut — et ce n’est pas par hasard.
Si vous gérez plus de trois services self-hostés, vous connaissez la douleur : un compte Nextcloud, un autre pour Grafana, un troisième pour Gitea, un quatrième pour Jellyfin. Votre Vaultwarden ressemble à un annuaire téléphonique. Authentik règle ce problème définitivement : un seul mot de passe, une seule MFA, et tous vos services s’alignent derrière.
Un fournisseur d’identité complet, pas un simple proxy
Authentik n’est pas un forward auth léger qui vérifie des headers HTTP. C’est un IdP (Identity Provider) complet, capable de parler tous les protocoles qu’une infrastructure moderne exige.
La stack technique est en Python (Django) pour le serveur principal et en Go pour les workers asynchrones. Le stockage repose sur PostgreSQL, avec Redis pour le cache et la gestion des sessions. La licence est MPL 2.0 — copyleft faible, pas de surprise commerciale.
Le périmètre protocolaire couvre tout ce qui existe :
- OAuth2 et OpenID Connect pour les applications modernes (Grafana, Gitea, Nextcloud)
- SAML 2.0 pour les services d’entreprise et les outils legacy
- LDAP pour l’intégration avec des annuaires existants ou des appliances NAS
- SCIM 2.0 pour le provisionnement automatique des utilisateurs
- Proxy authentication pour les applications qui ne supportent aucun standard — Authentik s’intercale devant et injecte l’identité dans les headers HTTP
La MFA couvre TOTP, WebAuthn (clés physiques FIDO2), Duo et les tokens statiques. Le tout est configurable par utilisateur, par groupe ou par application.
Des flux d’authentification que vous dessinez, pas que vous codez
Là où Keycloak vous enterre sous des écrans de configuration imbriqués et où Authelia vous demande d’écrire du YAML pour chaque scénario, Authentik propose un designer visuel de flux. Vous chaînez des stages — vérification de mot de passe, challenge TOTP, vérification d’empreinte navigateur, contrôle d’appartenance à un groupe — comme des blocs sur un canevas.
Ce modèle permet des politiques impossibles ailleurs sans code custom :
- Exiger la MFA uniquement depuis un réseau externe, la désactiver en VPN
- Bloquer l’accès à une application sensible si l’utilisateur n’a pas changé son mot de passe depuis 90 jours
- Rediriger vers un portail de consentement avant la première connexion à un nouveau service
- Injecter une vérification de risque (géolocalisation, empreinte navigateur) avant d’autoriser l’accès admin
Un flux, c’est une séquence de stages. Un stage, c’est une brique unitaire. La combinaison est infinie — et l’interface visuelle évite de perdre le fil entre trois fichiers YAML et un middleware Nginx.
Docker Compose : trois conteneurs, un annuaire
Le déploiement officiel repose sur Docker Compose avec quatre services :
- server : l’API et l’interface web (port 9000 en HTTP, 9443 en HTTPS)
- worker : les tâches asynchrones (envoi d’emails, nettoyage, événements)
- postgresql : la base de données principale
- redis : le cache et le bus de messages
Le docker-compose.yml de référence tient en une cinquantaine de lignes :
services:
postgresql:
image: docker.io/library/postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_PASSWORD: ${PG_PASS:?}
POSTGRES_USER: ${PG_USER:-authentik}
POSTGRES_DB: ${PG_DB:-authentik}
volumes:
- ./db:/var/lib/postgresql/data
redis:
image: docker.io/library/redis:alpine
restart: unless-stopped
command: --save 60 1 --loglevel warning
volumes:
- ./redis:/data
server:
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2025.12}
restart: unless-stopped
command: server
environment:
AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?}
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS:?}
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_ERROR_REPORTING__ENABLED: "true"
volumes:
- ./media:/media
- ./custom-templates:/templates
ports:
- "9000:9000"
depends_on:
- postgresql
- redis
worker:
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2025.12}
restart: unless-stopped
command: worker
environment:
AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?}
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS:?}
AUTHENTIK_REDIS__HOST: redis
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./media:/media
- ./certs:/certs
- ./custom-templates:/templates
depends_on:
- postgresql
- redisDeux variables d’environnement à générer avant le premier docker compose up -d :
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" > .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .envLa première connexion se fait sur http://<ip>:9000/if/flow/initial-setup/ pour créer le compte administrateur. Ensuite, mettez immédiatement un reverse proxy devant (Nginx Proxy Manager, Caddy, Traefik) avec Let’s Encrypt. Un port 9000 exposé nu sur Internet pendant la phase de setup, c’est une invitation à la compromission — le compte admin se crée en clair avant que vous n’ayez configuré quoi que ce soit.
La consommation au repos tourne autour de 500 Mo de RAM — plus lourd qu’Authelia (50-100 Mo) mais infiniment plus léger que Keycloak (1-2 Go minimum). Pour un homelab typique avec 2 Go de RAM disponibles, Authentik passe sans problème ; Keycloak, lui, ne démarre même pas.
Le proxy provider : la baguette magique pour les apps sans SSO
La fonctionnalité qui fait basculer le choix vers Authentik plutôt qu’Authelia, c’est le proxy provider intégré. Il fonctionne comme un forward auth classique — Authentik s’intercale entre votre reverse proxy et l’application, vérifie la session, et transmet ou bloque la requête — mais il est intégré au même outil que votre IdP.
Vous n’avez pas besoin de déployer un Authelia à côté d’un Keycloak pour couvrir à la fois les apps modernes (OIDC/SAML) et les apps legacy (auth par headers). Authentik fait les deux, dans la même interface, avec les mêmes groupes et les mêmes politiques.
Le flux pour protéger Uptime Kuma ou Portainer avec Authentik :
- Créer un Proxy Provider dans l’interface admin
- Définir l’URL interne de l’application (
http://uptime-kuma:3001) - Créer une Application qui référence ce provider
- Configurer le reverse proxy pour déléguer l’authentification à Authentik (
/outpost.goauthentik.io)
Vingt minutes, montre en main. Et l’utilisateur voit une page de login cohérente, avec le même thème et la même MFA, quelle que soit l’application protégée.
La comparaison qui tranche
Le verdict est mécanique. Authelia gagne si vous avez cinq services en HTTP basic auth et que vous voulez juste une couche de login unique par-dessus — le YAML suffit, la RAM est ridicule, le Go démarre en deux secondes. Keycloak gagne si vous gérez un parc de 500+ utilisateurs avec des fédérations Kerberos, des délégations SAML complexes et des exigences de conformité qui nécessitent un audit trail normé.
Pour tout le reste — le homelab de 10 à 50 services, la petite équipe de 5 à 50 développeurs, l’association qui héberge son Nextcloud et son GitLab — Authentik est le point d’équilibre exact. Assez léger pour tourner sur un VPS d’entrée de gamme, assez complet pour ne jamais vous faire dire « il me manque tel protocole », assez moderne pour que l’interface ne soit pas une punition.
Mettre Authentik en place avant qu’il ne soit trop tard
Le piège classique avec un IdP, c’est de le déployer après avoir accumulé quinze services avec quinze comptes séparés. La migration est alors un calvaire : il faut reconfigurer chaque application pour déléguer l’authentification, fusionner les comptes existants, gérer la transition sans coupure.
La bonne stratégie : déployez Authentik en premier, avant le prochain service que vous ajoutez à votre stack. Configurez le reverse proxy pour pointer les nouvelles applications vers le provider Authentik dès le départ. Pour les services existants, migrez-les un par un, en commençant par ceux qui supportent nativement OIDC — Nextcloud, Grafana, Gitea et Jellyfin ont tous des intégrations documentées.
Le temps total pour un setup complet — installation, reverse proxy, première application protégée — ne dépasse pas une heure. Le retour sur investissement est immédiat : vous ne retapez plus jamais un mot de passe.