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

Un seul compte pour toutes vos applications hébergées

Authentik est un serveur SSO (single sign-on) auto-hébergé : vos utilisateurs se connectent une fois, puis chaque application placée derrière lui accepte cette session au lieu de demander son propre mot de passe. L’installation repose sur un fichier Docker Compose officiel et deux secrets générés. La partie qui demande réellement de la réflexion vient ensuite : pointer un reverse proxy vers Authentik et placer une application existante derrière une authentification forward auth.

Authentik est déployé sous la forme de trois services dans ce fichier Compose : une base de données PostgreSQL, un processus server et un processus worker. Le conteneur serveur exécute également l’outpost intégré, qui détermine pour chaque application protégée si la requête provient d’un utilisateur authentifié. La version 2026.8.3 est la version actuelle en octobre 2026. Elle a été publiée le 17 septembre 2026 comme dernier correctif de la série 2026.8, ouverte avec la version 2026.8.0 le 18 août. Le fichier Compose officiel l’utilise désormais comme tag d’image par défaut. Le projet recommande un hôte doté d’au moins 2 cœurs CPU et de 2 GB de RAM. Considérez cela comme le minimum. PostgreSQL et le worker utilisent tous deux de la mémoire après une journée de fonctionnement du serveur.

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, avec postgresql indiquant healthy et server, et worker indiquant running. 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, limitez-le donc à moins de 99 caractères ; celui qui est généré est bien plus court. AUTHENTIK_SECRET_KEY signe les sessions et les tokens. Si vous le modifiez plus tard, tous les utilisateurs sont déconnectés et tous les tokens d’API que vous avez émis sont invalidés. Conservez .env avec le mode 600 et gardez-en une copie dans un emplacement sûr : une base de données restaurée sans la clé secrète correspondante est une base de données à laquelle personne ne peut se connecter.

Le fichier Compose indique que les deux valeurs sont 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. Si vous exécutez docker compose up -d depuis le mauvais répertoire, la commande affiche une ligne telle que required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required, puis s’arrête. Ce message indique 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 assistant de configuration initiale 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 un utilisateur administrateur normal pour votre propre usage sous Directory, puis Users, ajoutez-le au groupe authentik Admins et connectez-vous avec ce compte. Conservez akadmin comme compte d’urgence, avec un mot de passe long stocké hors ligne. Les opérations quotidiennes effectuées avec un compte intégré partagé rendent l’audit inexploitable, car chaque événement indique akadmin sans préciser qui a effectué l’action. Le même principe s’applique en aval d’Authentik : un outil tel que un harness OneCLI auto-hébergé qui fournit à chacun son propre agent ne produit une trace lisible que si l’identité qui lui est transmise appartient à une seule personne, et non à un compte 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 renforce encore cet argument : placez un service de support Chatwoot auto-hébergé derrière le même fournisseur et chaque personne répondant aux tickets se connecte une fois pour la journée 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 ; oublier 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 son authentification 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

Conservez ce dump avec .env. Le dump seul ne suffit pas, car la clé secrète qui protège les données de session et les tokens se trouve dans .env.

Les mises à niveau consistent à modifier un tag. Définissez AUTHENTIK_TAG dans .env sur la release souhaitée, puis exécutez docker compose pull suivi de docker compose up -d. Si vous n’avez jamais défini AUTHENTIK_TAG, la version provient de la valeur par défaut indiquée directement dans compose.yml. Dans ce cas, télécharger une version plus récente de ce fichier constitue la mise à niveau. C’est la méthode décrite dans la documentation officielle des mises à niveau. Lisez d’abord les notes de version. Authentik utilise des versions basées sur la date. En octobre 2026, sa documentation indique que les mises à niveau doivent suivre l’ordre des versions majeures : passez à la dernière version corrective de la série utilisée, puis parcourez chaque série suivante dans l’ordre, sans en sauter une. 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 fournisseur proxy, l’authentification transférée, OIDC (OpenID Connect), SAML et le moteur de workflows. Une offre entreprise payante ajoute du support et certaines fonctionnalités d’entreprise, mais aucune licence n’est nécessaire ici.

Traefik est-il nécessaire pour utiliser Authentik ?

Non. L’authentification transférée fonctionne avec nginx via auth_request et avec Caddy via forward_auth. Le principe est identique dans tous les cas : le reverse proxy interroge Authentik pour chaque requête, et le préfixe de chemin /outpost.goauthentik.io/ sur le nom d’hôte protégé doit être routé vers Authentik, et non 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é sur le fournisseur proxy 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 depuis une autre. Authentik considère donc chaque requête comme anonyme. Corrigez l’hôte externe, puis supprimez les cookies associés aux deux noms d’hôte avant de refaire un test.

De combien de RAM Authentik a-t-il besoin ?

La configuration minimale documentée est de 2 cœurs CPU et 2 GB de RAM en octobre 2026. Elle couvre PostgreSQL, le serveur et le worker. Sur une machine dotée de 2 GB de RAM, une pression mémoire peut déclencher l’OOM killer du kernel. Celui-ci termine le processus ayant le score de gravité le plus élevé : il correspond environ à la part de mémoire autorisée utilisée par le processus, à laquelle s’ajoute son oom_score_adj. Si 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.