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

Une seule connexion pour toutes les applications que vous hébergez

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

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 du serveur exécute également l’outpost intégré. Celui-ci détermine si la requête est authentifiée pour chaque application protégée. La version 2026.5 est la version actuelle en juillet 2026. 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 utilisent tous deux de la mémoire une fois que la machine fonctionne depuis une journée.

Prérequis

Vous avez besoin de Docker Engine avec le plugin Compose v2. Vous pouvez le vérifier avec docker compose version. Si cette commande affiche une erreur au lieu d’un numéro de version, installez le plugin avant de continuer. 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 qui pointe vers le serveur, auth.example.com dans les exemples ci-dessous. Authentik construit ses URL de redirection à partir du nom d’hôte utilisé par le navigateur.

Exécutez la stack avec un utilisateur standard membre du groupe docker, et non avec root. L’appartenance à ce groupe équivaut aux privilèges root sur l’hôte. Attribuez donc ce groupe à un seul compte de déploiement, et à personne d’autre, comme indiqué dans comptes utilisateur à privilèges minimaux sur un VPS.

Install with the official Compose file

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 should list three containers, with postgresql reporting healthy and server and worker reporting running. The first start runs the database migrations, so give it a minute before the web interface answers.

Both generated values matter, for different reasons. PG_PASS is the PostgreSQL password, and it has a hard limit of 99 characters. AUTHENTIK_SECRET_KEY signs sessions and tokens, so changing it later logs every user out and invalidates every API token you have issued. Keep .env at mode 600 and keep a copy somewhere safe, because a database restored without its matching secret key is a database nobody can log into.

The Compose file reads both values with the ${PG_PASS:?database password required} form, which means Compose refuses to start when the file is missing. Running docker compose up -d from the wrong directory prints required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required and stops. That message is a path problem, not a config problem.

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 trait de soulignement simple est ignoré sans avertissement. C’est la raison la plus courante pour laquelle un paramètre semble ne rien faire.

• 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, 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 paramètres, Authentik essaie 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 info ensuite.
• AUTHENTIK_ERROR_REPORTING__ENABLED vaut false par défaut. Définissez-le sur true uniquement si vous acceptez d’envoyer des rapports d’incident en amont.

Ces secrets se trouvent dans un fichier en clair. Traitez donc ce répertoire comme n’importe quel autre emplacement 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 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 utilisateur administrateur standard dans Directory, puis dans Users, ajoutez-le au groupe authentik Admins et connectez-vous avec ce compte. Conservez akadmin comme compte de secours d’urgence, avec un mot de passe long stocké hors ligne. L’utilisation quotidienne d’un compte intégré partagé détruit la traçabilité des opérations, car chaque événement indique akadmin sans préciser qui a effectué l’action.

Placer Authentik derrière votre reverse proxy

Publier le port 9000 sur Internet fonctionne, mais vous voulez utiliser TLS (transport layer security) et un vrai 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 de surcharge. 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 de surcharge. 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/. La commande doit répondre HTTP/2 200. Un 404 page not found de Traefik signifie que le conteneur n’est pas connecté au réseau proxy. Traefik ne peut pas router vers un conteneur qu’il ne peut pas atteindre.

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

Protéger une application avec forward auth

Le proxy provider d'Authentik propose trois modes. Choisir le mauvais mode 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 provient d'un utilisateur authentifié. 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).

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 provider. Ouvrez ensuite Outposts, modifiez 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, même correctement configuré, ne renvoie 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 est la liste des en-têtes 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 connaît jamais l'identité de l'utilisateur. Tout ce qui lit X-authentik-username pour effectuer une connexion automatique reste donc déconnecté.

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 second router est la partie 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 404, et la connexion n'aboutit jamais. La valeur priority, plus élevée, fait passer la règle de chemin spécifique avant la règle Host() simple sur le même domaine.

Testez 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 par tentative. Cela permet de vérifier si la requête a bien atteint Authentik.

Les erreurs que vous rencontrerez réellement

Boucle infinie de redirections entre l’application et la page de connexion. Le nom d’hôte externe du provider ne correspond pas à celui utilisé par le navigateur, généralement http:// dans le provider contre https:// dans la barre d’adresse. Le cookie de session est alors défini pour une autre origine. Chaque retour est donc interprété comme une nouvelle requête anonyme. Corrigez le nom d’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 catch-all pour cet hôte.

L’application se charge sans jamais demander de connexion. Le label 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 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. Il convient mieux aux environnements d’entreprise classiques qui utilisent intensivement la fédération SAML, le courtage des connexions provenant de plusieurs identity providers externes et l’exportation et l’importation de realms comme procédure de migration documentée. Pour certaines organisations, l’existence d’un support commercial est également importante sur le papier. En contrepartie, Keycloak ne fournit 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 à côté de Keycloak. Le proxy provider intégré d’Authentik fournit directement cette fonction. Il est déjà intégré, ce qui explique pourquoi la plupart des self-hosters qui utilisent un ensemble hétérogène d’applications choisissent Authentik.

Sauvegardes et mises à niveau

Trois éléments sont nécessaires pour effectuer 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 seul ne suffit pas, car la clé secrète qui protège les données de session et de token se trouve dans .env.

Les mises à niveau consistent à changer 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. Lisez d’abord les notes de version, car Authentik utilise des versions basées sur la date et certaines releases contiennent des migrations qui nécessitent de venir de la version 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 est présenté ci-dessus : 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 aucun élément de cette configuration 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 interroge Authentik pour chaque requête, et le préfixe de chemin /outpost.goauthentik.io/ sur le hostname 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é 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 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 hostnames avant de refaire un test.

De combien de RAM 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. Sur une machine disposant de 2 GB, le worker est le premier processus arrêté par le kernel en cas de pression mémoire. Les tâches en arrière-plan et l’envoi d’e-mails sortants s’arrêtent alors, 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.