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

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

Authentik est un serveur SSO auto-hébergé (single sign-on) : vos utilisateurs se connectent une seule fois, puis toutes les applications protégées 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. La partie qui demande le plus de réflexion vient ensuite : pointer un reverse proxy vers Authentik et placer une application existante derrière une authentification déportée.

Authentik est fourni 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 server exécute également l’outpost intégré, qui vérifie pour chaque application protégée si « cette requête est authentifiée ». La version 2026.5 est la version actuelle en juillet 2026. Le projet demande un hôte disposant d’au moins 2 cœurs CPU et de 2 GB de RAM. Considérez cette configuration comme le minimum. PostgreSQL et le worker consomment tous deux de la mémoire après une journée de fonctionnement du serveur.

Prérequis

Vous avez besoin de Docker Engine avec le plugin Compose v2. Vous pouvez le vérifier avec docker compose version. Si la commande affiche une erreur au lieu d’une version, installez le plugin avant de continuer. Les bases sont présentées dans exécuter des applications avec Docker Compose sur un VPS.

Vous avez également besoin d’un enregistrement DNS A qui pointe vers le serveur. Dans les exemples ci-dessous, il s’agit de auth.example.com. 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. Accordez-la donc à un seul compte de déploiement, conformément au principe présenté dans comptes utilisateur à 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. postgresql doit indiquer healthy et server, et worker doit indiquer running. Le premier démarrage exécute les migrations de la base de données. Attendez donc une minute avant d’accéder à l’interface web.

Les deux valeurs générées sont importantes, pour des raisons différentes. PG_PASS correspond au mot de passe PostgreSQL et sa longueur est limitée à 99 caractères. AUTHENTIK_SECRET_KEY signe les sessions et les jetons. Si vous le modifiez ultérieurement, tous les utilisateurs sont déconnectés et tous les jetons d’API é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 lit ces deux valeurs avec la forme ${PG_PASS:?database password required}. 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 required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required et s’arrête. Ce message indique un problème de chemin, pas un problème de configuration.

Les valeurs d’environnement importantes

Tout le reste se trouve dans le même fichier .env. Authentik associe un double trait de soulignement à une clé de configuration imbriquée. Ainsi, AUTHENTIK_EMAIL__HOST définit email.host. Un seul trait de soulignement est ignoré sans avertissement. C’est la raison la plus fréquente pour laquelle un paramètre semble ne produire aucun effet.

• AUTHENTIK_BOOTSTRAP_PASSWORD définit le mot de passe de l’utilisateur akadmin intégré lors du premier démarrage. Vous n’avez donc jamais à saisir ce mot de passe 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 d’API.
• COMPOSE_PORT_HTTP et COMPOSE_PORT_HTTPS déplacent les ports publiés par rapport aux valeurs 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 localhost sur le port 25. Les e-mails de réinitialisation du mot de passe se terminent alors par une erreur de connexion dans le journal du worker.
• AUTHENTIK_LOG_LEVEL=debug active le niveau de détail nécessaire lorsqu’un login flow ne fonctionne pas correctement. Rétablissez info ensuite.
• AUTHENTIK_ERROR_REPORTING__ENABLED vaut false par défaut. Définissez-le sur true uniquement si vous acceptez d’envoyer les rapports de crash au projet.

Ces secrets se trouvent 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 meilleur emplacement pour la copie de récupération qu’une note enregistrée sur votre ordinateur portable.

Première connexion et compte d’administration

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 votre propre compte d’administration normal dans Directory, puis Users, ajoutez-le au groupe authentik Admins et connectez-vous avec ce compte. Conservez akadmin comme compte break-glass, avec un mot de passe long stocké hors ligne. Le travail quotidien avec un compte intégré partagé détruit la traçabilité, car chaque événement indique akadmin sans préciser qui a effectué l’action. Cette règle s’applique également en aval d’Authentik : un système tel que un harness OneCLI auto-hébergé qui attribue à chaque personne son propre agent ne produit une traçabilité lisible que si l’identité qui lui est transmise correspond à 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 de Traefik comme reverse proxy pour plusieurs applications Compose, connectez Authentik au même réseau externe proxy avec un fichier 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 le fichier override. Le service server conserve donc tous les éléments du fichier officiel et reçoit les labels. Vérifiez le résultat avec curl -I https://auth.example.com/if/user/, qui doit répondre HTTP/2 200. Un 404 page not found de Traefik indique que le conteneur n’est pas connecté au réseau proxy. Traefik ne peut pas router les requêtes vers un conteneur qu’il ne peut pas joindre.

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

Protéger une application avec forward auth

Le proxy provider d’Authentik propose trois modes, et choisir le mauvais peut vous faire perdre une heure. Proxy signifie que l’outpost transfère lui-même le trafic vers l’application upstream. Forward auth (single application) signifie que votre reverse proxy continue de transférer le trafic et demande seulement à Authentik si la requête correspond à une session ouverte. Forward auth (domain level) protège toutes les applications d’un même domaine parent avec un seul provider, au prix de règles d’autorisation propres à chaque application. Avec Traefik en frontal, utilisez forward auth (single application). Pour vous exercer sur une application concrète, un espace de travail AFFiNE auto-hébergé constitue un bon premier choix. C’est le type d’outil interne que vous voulez rendre accessible depuis vos propres appareils, et depuis nulle part ailleurs. Pour un outil d’équipe, l’intérêt est encore plus évident : placez un centre de support Chatwoot auto-hébergé derrière le même provider afin que chaque personne qui répond aux messages ouvre une session une seule fois dans la journée, au lieu de partager encore un mot de passe.

Dans l’interface web, ouvrez Applications, puis Providers, créez un Proxy Provider, sélectionnez 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 provider. Ouvrez ensuite Outposts, modifiez le authentik Embedded Outpost et ajoutez la nouvelle application à ses applications sélectionnées. L’outpost ne répond que pour les applications qui lui sont attribuées. Si vous ignorez cette dernière étape, le provider peut être correctement configuré tout en ne renvoyant rien.

Définissez le middleware une seule fois, sur le conteneur Authentik, puis 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-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 correspond à la liste des headers que Traefik copie depuis la réponse d’Authentik vers la requête envoyée à l’upstream. Si vous l’omettez, l’application reste protégée, mais elle ne sait jamais quel utilisateur est connecté. Tout ce qui lit X-authentik-username pour ouvrir automatiquement une session reste donc déconnecté. Le problème est particulièrement visible devant une application qui gère sa propre connexion, comme un tracker d’entraînement openGym auto-hébergé avec sa connexion par passkey : les headers font la différence entre une seule demande et deux pour la même page.

L’application protégée elle-même a besoin de deux routers, et non d’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 deuxième router est celui que tout le monde oublie. Après la connexion, Authentik renvoie le navigateur vers un chemin situé sous /outpost.goauthentik.io/ sur le hostname de l’application, et non sur auth.example.com. Sans router qui envoie ce préfixe de chemin vers le service Authentik, la requête arrive sur votre application, qui renvoie une erreur 404, et la connexion n’aboutit jamais. La valeur supérieure de priority permet à la règle portant sur ce chemin précis de prendre le dessus sur la règle simple Host() du même domaine.

Testez la configuration dans une fenêtre de navigation privée. Vous devez être redirigé vers auth.example.com, vous connecter, puis revenir à l’application. docker compose logs -f server, côté Authentik, affiche un événement d’autorisation pour chaque tentative. Vous pouvez ainsi vérifier si la requête est bien arrivée jusqu’à Authentik.

Les échecs que vous rencontrerez réellement

Boucle de redirection infinie entre l’application et la page de connexion. L’hôte externe défini 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.

404 sur /outpost.goauthentik.io/start. Le routeur 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 n’est exécuté. Ouvrez le dashboard Traefik et vérifiez que le routeur référence bien le middleware.

403 renvoyé par Authentik après une connexion réussie. L’utilisateur est authentifié, mais il n’est pas autorisé. L’application applique une policy ou une exigence de groupe à laquelle cet utilisateur ne satisfait 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 choix le plus adapté aux besoins classiques des entreprises en matière d’identité : fédération SAML avancée, courtage des connexions provenant simultanément de plusieurs fournisseurs d’identité externes, et export/import de realm comme procédure de migration documentée. Le support commercial dont il bénéficie peut aussi compter pour certaines organisations. En contrepartie, Keycloak n’intègre pas son propre proxy. Pour protéger une application qui ne prend pas en charge OIDC (OpenID Connect), il faut donc exécuter un outil comme oauth2-proxy à ses côtés. Le proxy provider intégré d’Authentik remplit déjà ce rôle. C’est pourquoi la plupart des administrateurs qui s’auto-hébergent et utilisent un ensemble hétérogène d’applications choisissent Authentik.

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 et .env ensemble. 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. Consultez d’abord les notes de version, car Authentik utilise des versions basées sur des dates et certaines releases incluent des migrations qui exigent de partir de la précédente. Effectuez 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 indirecte, OIDC (OpenID Connect), SAML et le moteur de flux. Une offre entreprise payante ajoute du support et certaines fonctionnalités destinées aux entreprises, mais aucun élément présenté ici ne nécessite de licence.

Ai-je besoin de Traefik pour utiliser Authentik ?

Non. L’authentification indirecte 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 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 sur 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 mémoire vive Authentik a-t-il besoin ?

Le minimum documenté est de 2 cœurs CPU et 2 GB de RAM en juillet 2026. Cette valeur couvre PostgreSQL, le serveur et le worker ensemble. Sur une machine disposant de 2 GB de RAM, le worker est le premier processus que le noyau tue sous la pression mémoire. Le symptôme est l’arrêt des tâches en arrière-plan et des e-mails sortants, 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.