Authentik : installer un SSO auto-hébergé avec Docker

Un seul identifiant pour toutes les applications hébergées

Authentik est un serveur SSO (single sign-on) auto-hébergé : les utilisateurs se connectent une seule fois, puis toutes les applications placées derrière lui acceptent cette session au lieu de demander leur propre mot de passe. L’installation repose sur un fichier Docker Compose officiel et deux secrets générés. Le plus important vient ensuite : pointer un reverse proxy vers Authentik et placer une application existante derrière une authentification déléguée.

Authentik fournit trois services dans ce fichier Compose : une base de données PostgreSQL, un processus server et un processus worker. Le conteneur du serveur exécute également l’outpost intégré. C’est ce composant qui vérifie, pour chaque application protégée, si la requête provient d’un utilisateur connecté. La version 2026.8.5 est la version actuelle au 25 octobre 2026. Elle a été publiée le 21 octobre 2026 comme dernier correctif de la série 2026.8, commencée avec 2026.8.0 le 18 août. Elle remplace 2026.8.4 du 14 octobre comme tag d’image par défaut dans le fichier Compose officiel. Le projet demande un hôte équipé d’au moins 2 cœurs CPU et de 2 GB de RAM. Considérez cela comme le minimum. PostgreSQL et le worker conservent tous deux de la mémoire après une journée de fonctionnement.

Ce qu’il vous faut avant de commencer

Vous avez besoin de Docker Engine avec le plugin Compose v2. Vérifiez-le avec docker compose version. Si cette commande affiche une erreur au lieu d’une version, installez le plugin avant de poursuivre. Les bases sont expliquées dans exécuter des applications avec Docker Compose sur un VPS. Vous avez également besoin d’un enregistrement DNS A pointant vers le serveur, auth.example.com dans les exemples ci-dessous, car Authentik construit ses URL de redirection à partir du nom d’hôte utilisé par le navigateur.

Exécutez la stack avec un utilisateur standard appartenant au groupe docker, et non avec root. L’appartenance à ce groupe équivaut à root sur l’hôte. Réservez-la donc à un seul compte de déploiement, conformément au principe décrit dans comptes utilisateur avec privilèges minimaux sur un VPS.

Installer avec le fichier Compose officiel

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 doit lister trois conteneurs, tous démarrés, avec postgresql indiquant healthy une fois le contrôle réussi. Le premier démarrage exécute les migrations de la base de données. Attendez donc une minute avant d’ouvrir l’interface web.

Les deux valeurs générées sont importantes, pour des raisons différentes. PG_PASS est le mot de passe PostgreSQL. La documentation d’installation d’Authentik indique que les mots de passe de plus de 99 caractères ne sont pas pris en charge. Si vous choisissez vous-même un mot de passe, restez donc sous cette limite ; celui qui est généré est bien plus court. AUTHENTIK_SECRET_KEY est la clé qu’Authentik utilise pour signer les cookies. La documentation de configuration précise que sa modification invalide les sessions actives. Une nouvelle clé déconnecte donc tous les utilisateurs connectés. Conservez .env avec le mode 600 et gardez-en une copie dans un emplacement sûr avec vos sauvegardes, afin qu’une restauration utilise la même clé que le serveur d’origine.

Le fichier Compose marque les deux valeurs comme obligatoires avec la forme ${VAR:?message} : ${PG_PASS:?database password required} pour le service PostgreSQL et ${AUTHENTIK_SECRET_KEY:?secret key required} pour le serveur et le worker. Compose refuse donc de démarrer si le fichier est absent. L’exécution de docker compose up -d depuis le mauvais répertoire affiche une ligne telle que required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required, puis s’arrête. Ce message signale un problème de chemin, pas un problème de configuration.

Les variables d’environnement importantes

Toutes les autres valeurs vont dans le même fichier .env. Authentik convertit un double trait de soulignement en clé de configuration imbriquée. Ainsi, AUTHENTIK_EMAIL__HOST définit email.host. Un seul trait de soulignement ne permet pas d’accéder à la clé imbriquée. C’est la cause la plus fréquente lorsqu’un paramètre semble ne rien faire.

• AUTHENTIK_BOOTSTRAP_PASSWORD définit le mot de passe de l’utilisateur akadmin intégré au premier démarrage. Vous n’avez donc jamais besoin d’en saisir un dans un formulaire web public. AUTHENTIK_BOOTSTRAP_EMAIL et AUTHENTIK_BOOTSTRAP_TOKEN définissent de la même manière l’adresse de cet utilisateur et un jeton API.
• COMPOSE_PORT_HTTP et COMPOSE_PORT_HTTPS déplacent les ports publiés, qui utilisent par défaut 9000 et 9443.
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS et AUTHENTIK_EMAIL__FROM configurent l’envoi des e-mails. Sans ces variables, Authentik essaie d’utiliser localhost sur le port 25. Les e-mails de réinitialisation du mot de passe échouent alors avec une erreur de connexion dans le journal du worker.
• AUTHENTIK_LOG_LEVEL=debug active le niveau de détail nécessaire lorsqu’un flux de connexion ne fonctionne pas correctement. Rétablissez ensuite info.
• AUTHENTIK_ERROR_REPORTING__ENABLED vaut false par défaut. Définissez-le sur true uniquement si vous acceptez d’envoyer des rapports de plantage à l’éditeur.

Ces valeurs sont des secrets stockés dans un fichier en clair. Protégez donc ce répertoire comme n’importe quel autre espace de stockage d’identifiants. Un gestionnaire de mots de passe tel qu’une instance Vaultwarden auto-hébergée constitue un emplacement plus sûr pour conserver la copie de récupération qu’une note sur votre ordinateur portable.

Première connexion et compte administrateur

Ouvrez http://SERVER_IP:9000 dans un navigateur. Authentik affiche son parcours de configuration initial et vous demande de définir un mot de passe pour l’utilisateur akadmin par défaut. Si vous avez déjà défini AUTHENTIK_BOOTSTRAP_PASSWORD, cette étape est terminée et vous accédez directement à la page de connexion.

Créez votre propre utilisateur administrateur normal sous Directory, puis Users. Ajoutez-le au groupe authentik Admins et connectez-vous avec ce compte. Conservez akadmin comme compte de secours, avec un mot de passe long stocké hors ligne. Si un flow ou un stage défectueux vous bloque, docker compose run --rm server create_recovery_key 10 akadmin, exécuté depuis /opt/authentik, affiche un lien qui vous connecte directement avec akadmin. Toute personne qui possède ce lien dispose des mêmes accès. Traitez-le donc comme un mot de passe. Le travail quotidien avec un compte intégré partagé détruit la valeur du journal d’audit, car chaque événement indique akadmin sans préciser qui a effectué l’action. Le même problème se pose en aval d’Authentik : un outil tel que un harness OneCLI auto-hébergé qui fournit à chacun son propre agent ne produit une trace exploitable que si l’identité qui lui est transmise correspond à une seule personne, et non à un identifiant partagé par toute l’équipe.

Placer Authentik derrière votre reverse proxy

Publier le port 9000 sur Internet fonctionne, mais vous voulez utiliser TLS (transport layer security) et un véritable nom d’hôte. Si vous utilisez déjà la configuration décrite dans Traefik comme reverse proxy pour plusieurs applications Compose, rattachez Authentik au même réseau externe proxy avec un fichier d’override. Créez docker-compose.override.yml à côté de 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

Appliquez-le avec docker compose up -d. Compose fusionne automatiquement l’override. Le service server conserve donc tout le contenu du fichier officiel et reçoit les labels. Vérifiez avec curl -I https://auth.example.com/if/user/, qui doit répondre HTTP/2 200. Une réponse 404 page not found de Traefik signifie qu’aucun router ne correspond à la requête. Vérifiez que les labels ont bien été transmis au conteneur, que la règle Host() correspond exactement au nom d’hôte et que la requête est arrivée sur l’entry point HTTPS sur lequel le router écoute.

Une fois le nom d’hôte fonctionnel, liez les ports publiés à 127.0.0.1 dans l’override. Le proxy devient alors le seul point d’accès.

Protéger une application avec forward auth

Le fournisseur proxy d'Authentik propose trois modes, et choisir le mauvais peut vous faire perdre une heure. Proxy signifie que l'outpost lui-même transfère le trafic vers l'application en amont. Forward auth (single application) signifie que votre propre reverse proxy continue de gérer le trafic et demande simplement à Authentik si la requête est authentifiée. Forward auth (domain level) protège toutes les applications sous un domaine parent avec un seul fournisseur, au prix de règles d'autorisation par application. Avec Traefik en frontal, le mode forward auth (single application) est le choix recommandé. Si vous cherchez une application concrète pour vous entraîner, un espace de travail AFFiNE auto-hébergé est un bon premier candidat, car c'est le type d'outil interne que vous souhaitez rendre accessible depuis vos propres appareils et nulle part ailleurs. Un outil d'équipe rend la nécessité encore plus évidente : placez un service de support Chatwoot auto-hébergé derrière le même fournisseur et chaque personne répondant aux messages se connecte une fois par jour au lieu de partager un mot de passe supplémentaire.

Dans l'interface web, ouvrez Applications puis Providers, créez un Proxy Provider, choisissez le mode forward auth single application, et définissez l'hôte externe sur https://app.example.com. Créez une Application qui pointe vers ce fournisseur. Ensuite, ouvrez Outposts, modifiez le authentik Embedded Outpost, et ajoutez la nouvelle application dans ses applications sélectionnées. L'outpost ne répond que pour les applications qui lui ont été attribuées ; omettre cette dernière étape est la raison pour laquelle un fournisseur correctement configuré peut ne rien renvoyer.

Définissez le middleware une seule fois, sur le conteneur Authentik, et référencez-le depuis chaque application protégée :

      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-entitlements,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 est la liste des en-têtes que Traefik copie depuis la réponse d'Authentik vers la requête qu'il envoie en amont. Si vous l'omettez, l'application reste protégée, mais elle ne reçoit jamais l'identité de l'utilisateur ; par conséquent, tout ce qui lit X-authentik-username pour une connexion automatique restera déconnecté. Ce manque est particulièrement visible devant une application qui gère sa propre connexion, comme un suivi d'entraînement openGym auto-hébergé et sa connexion par passkey, où les en-têtes font la différence entre une seule invite de connexion et deux pour la même page.

L'application protégée elle-même nécessite deux routeurs, et non un seul :

    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

Le second routeur est l'élément que tout le monde oublie. Après une connexion, Authentik renvoie le navigateur vers un chemin sous /outpost.goauthentik.io/ sur le nom d'hôte de l'application, et non sur auth.example.com. Sans un routeur envoyant ce préfixe de chemin vers le service Authentik, la requête arrive sur votre application, qui répond par une erreur 404, et la connexion ne se termine jamais. La priorité priority plus élevée est ce qui permet à la règle de chemin spécifique de l'emporter sur la règle Host() générique sur le même domaine.

Testez dans une fenêtre de navigation privée. Vous devriez être redirigé vers auth.example.com, vous connecter, puis revenir sur l'application. docker compose logs -f server côté Authentik affiche un événement d'autorisation par tentative, ce qui vous indique si la requête a bien atteint Authentik.

Les erreurs que vous rencontrerez réellement

Boucle de redirection infinie entre l’application et la page de connexion. L’hôte externe configuré chez le fournisseur ne correspond pas à celui utilisé par le navigateur, généralement http:// chez le fournisseur contre https:// dans la barre d’adresse. Le cookie de session est alors défini pour une autre origine. Chaque retour est donc traité comme une nouvelle requête anonyme. Corrigez l’hôte externe et supprimez les cookies associés aux deux domaines avant de refaire le test.

Erreur 404 sur /outpost.goauthentik.io/start. Le routeur de l’outpost est absent ou sa priorité est inférieure à celle du routeur générique pour cet hôte.

L’application se charge sans jamais demander de connexion. Le libellé middlewares désigne un middleware qui n’existe pas. Traefik ne signale pas cette erreur. Une faute de frappe dans authentik@docker signifie donc simplement qu’aucun middleware ne s’exécute. Ouvrez le dashboard Traefik et vérifiez que le routeur référence bien le middleware.

Erreur 403 renvoyée par Authentik après une connexion réussie. L’utilisateur est authentifié, mais il n’est pas autorisé. L’application applique une association à une policy ou une exigence de groupe que cet utilisateur ne respecte pas. Le journal Events de l’interface d’administration indique la policy qui a refusé l’accès.

Quand Keycloak est le meilleur choix

Keycloak est le projet le plus ancien, soutenu par Red Hat. C’est le meilleur choix pour les besoins classiques de gestion des identités en entreprise : fédération SAML avancée, courtage des connexions provenant simultanément de plusieurs fournisseurs d’identité externes, ainsi qu’export et import de realm comme procédure de migration documentée. Pour certaines organisations, l’existence d’un support commercial est un critère important. En contrepartie, Keycloak n’intègre pas son propre proxy. Pour protéger une application qui ne parle ni OIDC (OpenID Connect) ni SAML, il faut donc exécuter un composant comme oauth2-proxy à ses côtés. Le proxy provider intégré d’Authentik fournit déjà cette fonction. Il est directement intégré, ce qui explique pourquoi la plupart des personnes qui auto-hébergent un ensemble hétérogène d’applications choisissent cette solution.

Sauvegardes et mises à niveau

Trois éléments permettent une restauration : la base de données PostgreSQL, le répertoire ./data et .env.

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

Stockez ce dump avec .env. Le dump ne contient aucune copie de AUTHENTIK_SECRET_KEY. Une restauration avec une autre clé invalide toutes les sessions actives. Conserver la clé d’origine permet donc au serveur restauré de reprendre son fonctionnement précédent.

Les mises à niveau consistent à modifier un tag. Définissez AUTHENTIK_TAG dans .env avec la version souhaitée, puis exécutez docker compose pull suivi de docker compose up -d. Si vous ne définissez jamais AUTHENTIK_TAG, la version provient de la valeur par défaut écrite directement dans compose.yml. Télécharger une copie plus récente de ce fichier constitue donc la mise à niveau. C’est la procédure décrite dans la documentation officielle des mises à niveau. Lisez d’abord les notes de version. Authentik utilise des versions basées sur des dates. En octobre 2026, sa documentation indique que les mises à niveau doivent suivre l’ordre des versions majeures : passez d’abord au dernier correctif de la série utilisée, puis avancez dans chaque série suivante sans en sauter aucune. Authentik ne prend pas en charge les retours à une version antérieure. Effectuez donc le dump de la base de données avant le pull, et non après.

FAQ

Authentik est-il gratuit en auto-hébergement ?

L’édition open source est gratuite et couvre tout ce qui précède : le proxy provider, forward auth, OIDC (OpenID Connect), SAML et le moteur de flows. Une offre enterprise payante ajoute du support et certaines fonctionnalités enterprise, mais rien de décrit ici ne nécessite de licence.

Ai-je besoin de Traefik pour utiliser Authentik ?

Non. Forward auth fonctionne avec nginx via auth_request et avec Caddy via forward_auth. Le principe est identique dans tous les cas : le reverse proxy demande à Authentik de vérifier chaque requête, et le préfixe de chemin /outpost.goauthentik.io/ sur le hostname protégé doit être routé vers Authentik plutôt que vers l’application.

Pourquoi mon application protégée alterne-t-elle indéfiniment entre la page de connexion et une erreur ?

L’hôte externe configuré dans le proxy provider ne correspond pas à l’URL utilisée par le navigateur, le plus souvent http au lieu de https. Le cookie de session est émis pour une origine et lu sur une autre. Authentik reçoit donc une requête anonyme à chaque tentative. Corrigez l’hôte externe, puis supprimez les cookies associés aux deux hostnames avant de recommencer le test.

Quelle quantité de RAM Authentik nécessite-t-il ?

Le minimum documenté est de 2 cœurs CPU et 2 GB de RAM en octobre 2026. Cette valeur couvre PostgreSQL, le serveur et le worker ensemble. Sur un serveur de 2 GB, la pression mémoire peut réveiller l’OOM killer du kernel. Celui-ci arrête le processus dont le score de gravité est le plus élevé : il correspond approximativement à la part de mémoire autorisée utilisée, augmentée de son oom_score_adj. Lorsque le processus concerné est le worker, les tâches en arrière-plan et les e-mails sortants s’arrêtent, tandis que la page de connexion continue de fonctionner. Prévoyez 4 GB si le même serveur exécute également les applications que vous protégez.