authentik : SSO et MFA open source auto-hébergés

Chaque nouvelle application métier apporte souvent sa propre base de comptes, sa propre politique de mots de passe et son propre processus de départ des collaborateurs. Résultat : des identités dispersées, des comptes orphelins oubliés après un départ et une surface d’attaque qui grandit au rythme du SI. Un fournisseur d’identité (IdP) centralisé règle ce problème en devenant le point unique d’authentification pour l’ensemble des services.

Dans l’écosystème open source, Keycloak a longtemps été la référence. authentik s’est imposé comme une alternative plus récente, pensée pour l’auto-hébergement, avec une interface d’administration moderne et un moteur de parcours d’authentification très flexible. Cet article présente son fonctionnement, son installation et les bonnes pratiques pour le déployer en production.

Qu’est-ce qu’authentik ?

authentik est un fournisseur d’identité open source, développé sur GitHub par le projet goauthentik et présenté par ses auteurs comme « la colle de l’authentification ». Il centralise la gestion des utilisateurs, des groupes et des accès, et expose ces identités aux applications via les protocoles standards du marché.

Protocoles SSO : OAuth2 / OpenID Connect, SAML, LDAP, RADIUS, SCIM, Kerberos et un mode proxy pour les applications qui ne gèrent aucun protocole d’authentification.
Authentification forte : TOTP, WebAuthn (clés FIDO2 et passkeys), codes de récupération statiques, Duo, SMS et e-mail, avec la possibilité de parcours sans mot de passe via WebAuthn.
Accès distant : la fonctionnalité RAC (Remote Access Control) donne un accès RDP ou SSH depuis le navigateur, sans client lourd.
Licence : le cœur du projet est sous licence MIT ; un dossier dédié contient les fonctions Enterprise, soumises à une licence distincte.

La version courante au moment de la rédaction est la 2026.8, publiée en septembre 2026. Le projet suit un rythme de versions nommées par année et par mois (2026.2, 2026.5, 2026.8…).

Architecture et fonctionnement

Un déploiement authentik repose sur trois briques principales :

Le serveur : il traite les requêtes API, l’exécution des parcours d’authentification et les requêtes SSO. Il embarque un routeur léger qui sert aussi les fichiers statiques, ainsi qu’un outpost intégré.
Le worker : il exécute les tâches de fond (envoi d’e-mails, notifications d’événements, tâches système visibles dans l’administration).
PostgreSQL : il stocke la configuration et les données. Depuis la version 2025.10, Redis n’est plus nécessaire : files de tâches, cache, sessions et WebSockets ont été migrés vers PostgreSQL. L’éditeur indique en contrepartie environ 50 % de connexions supplémentaires vers la base.

Les outposts sont des composants déployables au plus près des applications. Quatre types existent : Proxy, LDAP, RADIUS et RAC. Sur Docker Compose comme sur Kubernetes, authentik peut les créer et les gérer automatiquement.

La configuration s’articule autour de quelques notions clés : les applications (le service à protéger), les providers (le protocole utilisé pour cette application : OIDC, SAML, proxy…), les flows (parcours d’authentification, d’inscription, de récupération) composés de stages (identification, mot de passe, validation MFA, consentement…), et les policies qui conditionnent l’exécution d’un stage ou l’accès à une application. Les sources permettent enfin de fédérer des annuaires ou fournisseurs externes (LDAP, OAuth, SAML).

Installation avec Docker Compose

La documentation officielle recommande Docker Compose pour les petites installations et les tests, et le chart Helm pour Kubernetes sur les environnements plus importants. Les prérequis sont modestes : au moins 2 cœurs CPU, 2 Go de RAM et Docker Compose v2 (ou Podman). Si vous débutez avec les conteneurs, notre cours d’introduction à Docker pose les bases nécessaires.

L’installation se fait en quatre commandes : téléchargement du fichier Compose officiel, génération du mot de passe PostgreSQL et de la clé secrète dans un fichier .env, puis démarrage des conteneurs.

# Télécharger le fichier Compose officiel
wget https://docs.goauthentik.io/compose.yml

# Générer les secrets (mot de passe PostgreSQL de 99 caractères max)
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env

# Démarrer authentik
docker compose pull
docker compose up -d

Premiers pas et cas d’usage

Une fois les conteneurs démarrés, rendez-vous sur http://<IP ou nom du serveur>:9000 pour définir le mot de passe du compte administrateur par défaut akadmin. Par défaut, authentik écoute sur le port 9000 en HTTP et 9443 en HTTPS.

Protéger une application compatible OIDC ou SAML. Dans l’interface d’administration, l’assistant de création d’application crée en une seule étape l’application et son provider. Vous récupérez l’identifiant client, le secret et les URL de découverte à renseigner côté application (GitLab, Grafana, Nextcloud, Proxmox, etc.). L’accès peut ensuite être restreint à un groupe via une policy ou un binding.

Protéger une application sans SSO natif. Le provider Proxy place authentik devant l’application : l’utilisateur s’authentifie avant d’atteindre le service. Il peut fonctionner en reverse proxy complet ou en mode forward auth derrière un reverse proxy existant comme Traefik, Nginx ou Caddy. L’outpost intégré au serveur suffit pour démarrer, sans déploiement supplémentaire.

Imposer l’authentification forte. Pour généraliser l’authentification multifacteur, ajoutez au flow d’authentification un stage « Authenticator Validation » qui accepte les classes d’authentificateurs souhaitées (TOTP, WebAuthn…). Pour un parcours sans mot de passe, un flow composé de ce stage limité à WebAuthn puis d’un stage de connexion suffit ; l’autoremplissage des passkeys s’active dans le stage d’identification et nécessite un identifiant découvrable.

Servir d’annuaire LDAP ou RADIUS. Les outposts LDAP et RADIUS exposent les utilisateurs authentik à des équipements ou logiciels anciens qui ne parlent que ces protocoles (NAS, Wi-Fi d’entreprise, VPN). À l’inverse, une source LDAP permet de synchroniser les comptes d’un annuaire existant vers authentik.

Industrialiser la configuration. Les blueprints sont des fichiers YAML qui décrivent des objets authentik (flows, applications, providers). Placés dans le répertoire /blueprints du conteneur, ils sont découverts et appliqués automatiquement ; un flow peut aussi être exporté depuis l’interface. C’est la voie à privilégier pour versionner la configuration dans Git.

Exposition et mises à jour

Pour écouter directement sur les ports 80 et 443, ajoutez deux variables au fichier .env puis relancez les conteneurs. Pour une mise à jour, la documentation indique que le fichier Compose pointe vers la dernière version publiée au moment du téléchargement : il suffit de le télécharger à nouveau, après avoir sauvegardé la base PostgreSQL et lu les notes de version.

# Exposer authentik sur les ports standards
echo "COMPOSE_PORT_HTTP=80" >> .env
echo "COMPOSE_PORT_HTTPS=443" >> .env
docker compose up -d

# Mise à jour : récupérer le dernier compose.yml puis redéployer
wget -O compose.yml https://docs.goauthentik.io/compose.yml
docker compose pull
docker compose up -d

authentik face aux alternatives

Keycloak : projet historique très éprouvé, adossé à la CNCF, extrêmement complet sur OIDC et SAML. Sa personnalisation passe davantage par des extensions Java et des thèmes. authentik se distingue par ses flows composables depuis l’interface, ses outposts LDAP, RADIUS et RAC intégrés et une prise en main plus rapide en auto-hébergement.
Authelia : portail d’authentification léger, centré sur le forward auth et le MFA devant un reverse proxy, configuré par fichiers. Idéal pour un périmètre simple ; authentik couvre un spectre plus large (gestion des utilisateurs en interface, SAML, LDAP sortant, accès distant).
Microsoft Entra ID, Okta : services SaaS sans infrastructure à maintenir, mais facturés à l’utilisateur et hébergés hors de votre périmètre. authentik garde les identités chez vous, un argument fort pour la souveraineté des données.

Côté modèle économique, la version open source inclut les protocoles SSO, l’accès RDP/SSH web et le support communautaire. L’offre Enterprise (5 $ par utilisateur et par mois pour les comptes collaborateurs, facturation annuelle) ajoute notamment la gestion des accès à privilèges, l’intégration Microsoft Entra ID et Google Workspace, le mTLS, l’historique des mots de passe, la journalisation d’audit avancée et un support éditeur.

Bonnes pratiques de déploiement

Sécurisez le compte akadmin : mot de passe long, MFA WebAuthn dès la première connexion, puis comptes d’administration nominatifs dans un groupe dédié.
Placez authentik derrière HTTPS avec un certificat valide et un nom de domaine dédié (par exemple auth.votredomaine.fr) : les flux OIDC et SAML reposent sur des redirections qui doivent être fiables.
Sauvegardez PostgreSQL et le fichier .env : la clé AUTHENTIK_SECRET_KEY est indispensable à la restauration. Testez la restauration avant chaque mise à jour majeure.
Prévoyez la haute disponibilité : l’IdP devient un point de passage obligé ; s’il tombe, plus personne ne se connecte. Sur Kubernetes, multipliez les réplicas du serveur et du worker et adossez-les à un PostgreSQL redondant.
Dimensionnez la base : depuis la suppression de Redis, PostgreSQL absorbe davantage de connexions ; ajustez max_connections ou utilisez un pooler.
Exploitez les événements : connexions, échecs et modifications d’administration sont journalisés ; transférez-les vers votre SIEM et configurez des notifications sur les événements sensibles.
Versionnez la configuration avec les blueprints et conservez un compte de secours documenté en cas de flow mal configuré.

Conclusion

authentik apporte à une PME ou à une DSI un fournisseur d’identité complet, auto-hébergé et sous licence MIT, capable de couvrir aussi bien les applications modernes (OIDC, SAML) que les équipements historiques (LDAP, RADIUS) et l’accès distant. Son installation tient en quelques commandes et sa suppression de Redis simplifie encore l’exploitation. Il reste un composant critique : traitez-le comme tel, avec MFA pour les administrateurs, sauvegardes testées et supervision. C’est une brique de choix pour avancer vers une architecture où chaque accès est vérifié et centralisé.

Partagez cet article !