Installer et configurer authentik:SSO, durcissement et exemples concrets
Dernière mise à jour : Février 2026 | Version de référence : authentik 2025.12.x
authentik est un fournisseur d’identité (Identity Provider, IdP) open source, conçu pour fédérer l’authentification et l’autorisation sur l’ensemble des applications. Il prend en charge les protocoles standards du marche : OIDC/OAuth2, SAML 2.0, LDAP, RADIUS, ainsi qu’un mode Proxy permettant de protéger les applications qui ne gèrent pas nativement ces protocoles. Depuis la version 2025.10, authentik s’inscrit dans une démarche de simplification de sa pile technique, notamment avec la suppression de la dépendance à Redis, ce qui en fait une solution encore plus accessible pour les déploiements auto-hébergés.
Dans ce guide nous voyons pas à pas dans le déploiement d’authentik sur une machine Rocky Linux 9 via Docker Compose, puis nous détaillerons la configuration des intégrations SSO et les mesures de durcissement indispensables pour un bon usage.
1. Architecture et composants d’authentik
Avant de plonger dans l’installation, il est utile de comprendre comment authentik s’organise en interne. L’architecture repose sur un ensemble de composants conteneurisés qui interagissent entre eux.
1.1 Les briques fondamentales
Un déploiement Docker Compose standard d’authentik (versions 2025.10 et supérieures) comporte trois conteneurs principaux :
- Le conteneur « server » constitue le cœur applicatif. Il se décompose en deux sous-composants : le serveur principal (Core) et un outpost embarque. Un routeur interne légers dirige les requêtes entrantes soit vers le Core (pour le traitement des flux d’authentification, l’API, l’interface d’administration), soit vers l’outpost embarque (pour le mode proxy). Ce conteneur héberge également les fichiers statiques (JavaScript, CSS) et sert les ressources uploadées (icônes, arrière-plans de flux).
- Le conteneur « worker » est dédie aux taches de fond. Il gère l’envoi d’e-mails, le système de notifications, la synchronisation LDAP, l’exécution des taches planifiées et le traitement des évènements. Depuis la version 2025.8, le worker utilise le mécanisme LISTEN/NOTIFY de PostgreSQL pour la distribution des taches, ce qui élimine tout besoin de broker de messages externe. Techniquement, authentik s’appuie sur le framework Dramatiq, interface via le package django-dramatiq-postgres.
- Le conteneur PostgreSQL constitue la couche de persistance. Il stocke l’intégralité de la configuration, des données utilisateurs, des sessions, du cache et des files d’attente de taches. Depuis la version 2025.10, PostgreSQL remplace également Redis pour le cache et les connexions WebSocket. Il est à noter que cette consolidation entraine environ 50 % de connexions supplémentaires vers PostgreSQL par rapport aux versions antérieures.
1.2 Schéma d’architecture
Le schéma ci-dessous illustre le parcours d’une requête d’authentification et les dépendances entre les composants :
1.3 La suppression de Redis : un tournant architectural
Historiquement, authentik utilisait Redis pour le cache, les sessions du proxy embarque, les connexions WebSocket et la file d’attente des taches de fond. L’équipe de développement a mené un travail progressif de migration, étale sur quatre versions majeures :
En 2024.6, les verrous distribues ont été migres vers les advisory locks de PostgreSQL. En 2025.4, les sessions utilisateur ont été déplacés en base de données. En 2025.8, le système de taches de fond a basculé sur LISTEN/NOTIFY. Enfin, en 2025.10, le cache, l’outpost embarque et les WebSocket ont rejoint PostgreSQL, rendant Redis entièrement obsolète.
Cette décision s’inscrit dans une philosophie assumée par l’équipe d’Authentik Security : réduire le nombre de dépendances pour simplifier l’auto-hébergement. Un composant de moins signifie un point de défaillance en moins, moins de maintenance et une surface d’attaque réduite. Du cote des performances, les sessions utilisateur ont bénéficié d’améliorations significatives grâce à des jointures optimisées qui économisent deux à trois requêtes par requête HTTP. Le seul point de régression notable concerne le provider RAC (Remote Access Control), ou la latence est légerement supérieure à celle obtenue avec Redis.
2. Pré-requis système (Rocky Linux 9)
Matériel minimum recommande : 2 vCPU, 4 Go de RAM, 40 Go de stockage. Le stockage NVMe est recommandé pour les performances de PostgreSQL.
Logiciel : Rocky Linux 9 à jour, accès root ou sudo, un nom de domaine (FQDN) résolvable pointé vers le serveur, et une connectivité réseau sur les ports 80 et 443 (via reverse proxy).
2.1 Mise à jour du système
######################################## # Mise à jour complète du système ######################################## sudo dnf -y update sudo reboot
Après le redémarrage, on vérifie la version du noyau et l’état de SELinux :
######################################## # Vérification post-reboot ######################################## uname -r cat /etc/os-release | grep PRETTY_NAME getenforce
SELinux est activé par défaut sur Rocky Linux 9 en mode Enforcing. Il est recommandé de le conserver ainsi. Docker fonctionne avec SELinux sans configuration supplémentaire depuis plusieurs versions.
3. Installation de Docker et Docker Compose sur Rocky Linux 9
nous adoptons cette méthode qu’à l’installation de Podman (fourni par défaut) car authentik est testé et documenté pour Docker.
3.1 Ajout du dépôt Docker et installation
######################################## # Installation de Docker Engine sur Rocky Linux 9 # Source : dépôt officiel Docker pour RHEL ######################################## # Installer le plugin de gestion des depots sudo dnf -y install dnf-plugins-core # Ajouter le dépôt Docker CE pour RHEL sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo # Installer Docker Engine, CLI, containerd et les plugins sudo dnf -y install docker-ce docker-ce-cli containerd.io \ docker-buildx-plugin docker-compose-plugin # Activer et démarrer Docker sudo systemctl --now enable docker # Vérifier l'installation docker --version docker compose version
La commande systemctl --now enable combine l’activation au démarrage et le lancement immédiat du service. Le plugin docker-compose-plugin intègre Docker Compose v2 directement dans la CLI Docker, ce qui permet d’utiliser docker compose (sans tiret) au lieu de l’ancien binaire docker-compose.
3.2 Autoriser un utilisateur non-root (optionnel mais recommande)
######################################## # Ajouter l'utilisateur courant au groupe docker ######################################## sudo usermod -aG docker $(whoami) # Se déconnecter puis se reconnecter pour prendre en compte le groupe newgrp docker # Vérifier l'appartenance au groupe id
Cette étape évite de préfixer chaque commande Docker par sudo. Néanmoins, on garde à l’esprit que tout membre du groupe docker dispose de fait d’un accès équivalent à root sur le système hôte (via le socket Docker).
4. Configuration du pare-feu (firewalld)
Rocky Linux 9 utilise firewalld comme gestionnaire de pare-feu par défaut. Il est essentiel de n’exposer que les ports strictement nécessaires. Seuls les ports 80 (HTTP, pour la redirection vers HTTPS) et 443 (HTTPS) doivent être accessibles depuis l’extérieur.
4.1 Ouvrir les ports HTTP et HTTPS
######################################## # Ouvrir HTTP/HTTPS de manière permanente ######################################## sudo firewall-cmd --zone=public --add-service=http --permanent sudo firewall-cmd --zone=public --add-service=https --permanent sudo firewall-cmd --reload # Verifier les services ouverts sudo firewall-cmd --list-services
4.2 Exposition directe d’authentik (environnement de test uniquement)
Pour tester rapidement, vous pourra ouvrir temporairement les ports 9000 (HTTP) et 9443 (HTTPS) utilisés par authentik. Cette configuration est fortement déconseillée en utilisation nominale.
######################################## # (Test uniquement) Ouvrir les ports authentik ######################################## sudo firewall-cmd --zone=public --add-port=9000/tcp --permanent sudo firewall-cmd --zone=public --add-port=9443/tcp --permanent sudo firewall-cmd --reload
4.3 Note sur Docker et firewalld
Docker manipule directement les règles iptables/nftables pour le routage des conteneurs, ce qui peut contourner les règles firewalld dans certains cas. Pour maitriser finement le filtrage réseau des conteneurs, on pourra configurer le daemon Docker avec l’option "iptables": false dans /etc/docker/daemon.json et gérer manuellement les règles. C’est une approche avancée qui mérite d’être documentée.
5. Déploiement d’authentik via Docker Compose
5.1 Préparer l’arborescence de déploiement
######################################## # Créer le répertoire de travail ######################################## sudo mkdir -p /opt/authentik sudo chown -R $(whoami):$(whoami) /opt/authentik cd /opt/authentik
5.2 Télécharger le fichier Docker Compose et générer les secrets
La documentation officielle d’authentik met à disposition un fichier docker-compose.yml préconfiguré. Chaque version majeure d’authentik dispose de son propre fichier Compose versionné. Il est recommandé de toujours télécharger le fichier correspondant à la version que l’on souhaite déployer.
######################################## # Télécharger le docker-compose.yml officiel # et générer le fichier .env avec les secrets ######################################## cd /opt/authentik # Fichier Compose officiel (version courante) wget -O docker-compose.yml https://docs.goauthentik.io/docker-compose.yml # Générer un mot de passe PostgreSQL (99 caracteres max, limitation PostgreSQL) echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env # Générer la clé secrète authentik echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env # Verifier le contenu du fichier .env cat .env
5.3 Variables d’environnement optionnelles
Le fichier .env peut être enrichi avec plusieurs paramètres utiles :
######################################## # Variables optionnelles pour .env ######################################## # Modifier les ports exposes (ex : mettre authentik sur 80/443) # COMPOSE_PORT_HTTP=80 # COMPOSE_PORT_HTTPS=443 # Activer le reporting d'erreurs (optionnel) # AUTHENTIK_ERROR_REPORTING__ENABLED=true # Configuration SMTP pour les notifications et l'envoi d'e-mails # AUTHENTIK_EMAIL__HOST=smtp.homelab.com # AUTHENTIK_EMAIL__PORT=587 # [email protected] # AUTHENTIK_EMAIL__PASSWORD=VotreMotDePasseSMTP # AUTHENTIK_EMAIL__USE_TLS=true # [email protected]
La configuration SMTP est vivement recommandée : elle permet à authentik d’envoyer les e-mails de vérification, de récupération de mot de passe et les alertes système.
5.4 Démarrer la stack
######################################## # Télécharger les images et démarrer ######################################## docker compose pull docker compose up -d # Vérifier que tous les conteneurs sont en cours d’exécution docker compose ps # Consulter les logs en temps reel (Ctrl+C pour quitter) docker compose logs -f --tail=50
Nous devons attendre que les logs affichent des messages de type "Starting authentik server" et que le health check de PostgreSQL passe au vert avant de continuer.
5.5 Configuration initiale (création du compte administrateur)
L’assistant de configuration initiale est accessible via un chemin spécifique. Il est impératif d’inclure le slash final dans l’URL, sans quoi nous abtenons une erreur « Not Found ».
######################################## # URL de configuration initiale ######################################## http://auth.homelab.lan:9000/if/flow/initial-setup/
Cette page invite à définir le mot de passe du compte akadmin, qui est le super-utilisateur par defaut d’authentik. On choisira bien évidemment un mot de passe robuste et on le conserve en lieu sur ( comme un gestionnaire de mots de passe).
6. Sécurité des conteneurs : fuseau horaire et UTC
Authentik effectue l’ensemble de ses opérations internes en UTC. L’interface utilisateur se charge ensuite de localiser les horaires en fonction du navigateur. La documentation officielle met en garde contre le montage de /etc/timezone ou /etc/localtime dans les conteneurs authentik : cette pratique provoque des dysfonctionnements avec les protocoles OAuth2 et SAML, dont les mécanismes de validation reposent sur des horodatages précis.
Cote système hôte, on peut (et doit) configurer le fuseau horaire normalement. En revanche, on ne propagera jamais cette configuration à l’intérieur des conteneurs authentik.
######################################## # Configurer le fuseau horaire du système hôte # (ne PAS monter dans les conteneurs) ######################################## sudo timedatectl set-timezone Europe/Paris timedatectl status
7. Exposition HTTPS : mise en place du reverse proxy
En fonctionnement nominal, l’interface d’administration et les endpoints SSO doivent impérativement être servis en HTTPS avec un certificat valide. Le reverse proxy se place entre les utilisateurs et authentik, il centralise la terminaison TLS et permet de ne pas exposer les ports internes d’authentik sur le réseau.
Exemple avec Nginx
######################################## # Exemple de configuration Nginx # Fichier : /etc/nginx/conf.d/authentik.conf ######################################## # Bloc upstream pour les connexions persistantes upstream authentik { server :9000; keepalive 10; } server { listen 443 ssl http2; server_name auth.homelab.com; ssl_certificate /etc/letsencrypt/live/auth.homelab.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/auth.homelab.com/privkey.pem; # En-tetes de securite add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always; add_header X-Content-Type-Options nosniff; add_header X-Frame-Options SAMEORIGIN; location / { proxy_pass http://authentik; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; # Support WebSocket (necessaire pour certaines fonctionnalites) proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } # Redirection HTTP vers HTTPS server { listen 80; server_name auth.homlab.com; return 301 https://$server_name$request_uri; }
Les en-têtes X-Forwarded-Proto et X-Forwarded-For sont essentiels : authentik s’en sert pour déterminer le protocole d’accès (HTTPS) et l’adresse IP réelle du client, informations critiques pour la génération des tokens et la journalisation.
8. Outposts et Proxy Provider
8.1 Le concept d’outpost
Un outpost est un composant d’authentik dédié à l’application des politiques d’authentification au plus près des applications. L’outpost embarqué, inclus dans le conteneur serveur, couvre la plupart des cas d’usage. Des outposts externes peuvent être déployés pour des architectures distribuées ou pour des raisons de cloisonnement.
Le Proxy Provider est un type de provider qui permet de protéger des applications ne supportant pas nativement les protocoles SSO (OIDC, SAML). Il fonctionne en mode reverse-proxy ou forward-auth : le proxy intercepte la requête, vérifie l’authentification auprès d’authentik, puis transmet la requête à l’application si l’utilisateur est autorisé.
8.2 Le montage du socket Docker : comprendre les risques
Par défaut, le fichier Docker Compose officiel monte le socket Docker (/var/run/docker.sock) dans le conteneur worker. Cela permet à authentik de déployer et gérer automatiquement les outposts Docker. Toutefois, cette pratique présente un risque de sécurité significatif : un accès au socket Docker équivaut à un accès root sur l’hôte.
La documentation officielle recommande deux approches pour atténuer ce risque :
Option 1 : Docker Socket Proxy. Déploiement d’un conteneur intermédiaire (comme tecnativa/docker-socket-proxy) qui filtre les appels API Docker autorisés. Cela permet de n’exposer que les permissions nécessaires au worker.
Option 2 : Gestion manuelle des outposts. Suppression du montage du socket et déploiement des outposts manuellement via Docker Compose ou un orchestrateur. C’est l’approche la plus sécurisée.
######################################## # Vérifier le montage du socket Docker ######################################## docker compose exec worker sh -lc "ls -l /var/run/docker.sock || true"
9. Configuration SSO : le modèle « Provider + Application »
L’architecture logique d’authentik repose sur deux concepts complémentaires. Le Provider représente le protocole et la méthode d’authentification (OAuth2/OIDC, SAML, LDAP, Proxy, RADIUS). L’Application est l’objet cote portail qui associe un usage utilisateur (nom, icône, lien) à un provider technique. Pour chaque service à intégrer, on crée donc un provider et une application associée.
9.1 Intégration OIDC (OpenID Connect)
OpenID Connect est le protocole le plus répandu pour les intégrations modernes. Il s’appuie sur OAuth 2.0 et permet l’échange de tokens d’identité au format JWT. Voici la procédure générale pour connecter une application compatible OIDC à authentik :
Etape 1 : Dans l’interface d’administration d’authentik, naviguer vers Applications > Providers et créer un nouveau provider de type OAuth2/OpenID Connect.
Etape 2 : Configurer le Redirect URI (ou callback URL) tel que spécifié par l’application cible. Par exemple, pour Nextcloud,
https://cloud.homelab.lan/apps/oidc_login/oidc
Etape 3 : Récupérer le Client ID et le Client Secret générés automatiquement par authentik.
Etape 4 : Cote application, renseigner l’URL de découverte OpenID (
https://auth.homelab.com/application/o/nextcloud/.well-known/openid-configuration
), le Client ID, le Client Secret et les scopes requis (typiquement openid profile email).
Etape 5 : Créer une application dans authentik, l’associer au provider et définir les politiques d’accès souhaitées.
9.2 Intégration SAML 2.0
SAML 2.0 reste le standard de référence dans de nombreux environnements d’entreprise. authentik peut agir comme Identity Provider SAML pour tout Service Provider compatible. La configuration passe par la création d’un provider SAML avec les paramètres suivants :
- L’ACS URL (Assertion Consumer Service) est l’endpoint du Service Provider ou authentik enverra la réponse SAML.
- L’Issuer identifie de manière unique l’IdP (authentik) auprès du SP.
- L’Audience (ou Entity ID du SP) identifie le Service Provider.
- LesProperty Mappings définissent quels attributs utilisateur sont transmis dans l’assertion SAML (e-mail, nom, groupes, etc.).
- L’import de métadonnées XML est également possible : si le Service Provider fournit un fichier de métadonnées, authentik peut le consommer directement pour pré-remplir la configuration.
9.3 Intégration LDAP
Authentik peut exposer un endpoint LDAP via un outpost dédié, permettant aux applications qui ne supportent que LDAP (comme certains équipements réseau ou logiciels anciens) de s’authentifier contre le référentiel utilisateur d’authentik. Il peut également se connecter en tant que source LDAP vers un Active Directory ou un OpenLDAP existant pour importer et synchroniser les comptes.
10. GeoIP : géolocalisation des connexions
Authentik peut exploiter une base de données GeoIP au format MaxMind pour enrichir les évènements de sécurité avec des informations de géolocalisation. Cela s’avère précieux pour les politiques d’accès conditionnel (bloquer les connexions depuis certains pays, alerter sur les connexions inhabituelles).
######################################## # Ajouter GeoIP au fichier .env # (nécessite un compte gratuit MaxMind) ######################################## echo "GEOIPUPDATE_ACCOUNT_ID=VotreAccountID" >> .env echo "GEOIPUPDATE_LICENSE_KEY=VotreLicenseKey" >> .env echo "AUTHENTIK_AUTHENTIK__GEOIP=/geoip/GeoLite2-City.mmdb" >> .env
11. Vérifications, exploitation et mises à jour
11.1 Vérifier la configuration effective
Authentik fournit une commande permettant d’afficher la configuration active, ce qui est utile pour valider que vos variables d’environnement et surcharges sont correctement prises en compte :
######################################## # Afficher la configuration active (lecture seule) ######################################## docker compose run --rm worker ak dump_config
11.2 Vérifier l’état de santé des services
######################################## # Vérification de l’état des conteneurs ######################################## docker compose ps # Tester l'endpoint de santé d'authentik curl -s http://:9000/-/health/ready/ | head # Consulter les logs d'un service spécifique docker compose logs server --tail=100 docker compose logs worker --tail=100
11.3 Stratégie de sauvegarde
La sauvegarde d’une instance authentik repose sur deux éléments : le dump de la base PostgreSQL et la copie des fichiers uploades (icônes, certificats, templates). Depuis la version 2025.12, les fichiers sont stockes dans le répertoire /data (et non plus /media).
######################################## # Sauvegarde PostgreSQL ######################################## docker compose exec postgresql pg_dump -U authentik authentik > backup_$(date +%Y%m%d).sql # Sauvegarde des fichiers uploades tar czf authentik_data_$(date +%Y%m%d).tar.gz ./data/ ./certs/ ./custom-templates/
Nous pouvons automatiser ces sauvegardes via cron et valider régulièrement le processus de restauration. Dans le cas du homelab, le serveur est une VM dans proxmox à ce titre des bakcup régulier sont effectués.
11.4 Mise à jour d’authentik
La documentation de mise à jour insiste sur plusieurs points essentiels. Les mises à jour doivent suivre la séquence des versions majeures sans en sauter : si nous sommes en 2025.4, nous passons d’abord en 2025.6, puis en 2025.8, puis en 2025.10, etc. Chaque version mineure la plus récente doit être atteinte avant de passer à la version majeure suivante. Les outposts doivent toujours être à la même version que le serveur authentik. Enfin, authentik ne supporte pas les retours en arrière : donc on sauvegarde la base avant chaque mise à jour.
######################################## # Procédure de mise à jour (exemple vers 2025.12) ######################################## # 1. Sauvegarder la base docker compose exec postgresql pg_dump -U authentik authentik > backup_pre_upgrade.sql # 2. Télécharger le nouveau docker-compose.yml wget -O docker-compose.yml https://goauthentik.io/version/2025.12/docker-compose.yml # 3. Appliquer la mise à jour docker compose up -d --remove-orphans
Le flag --remove-orphans supprime les conteneurs definis dans l’ancien fichier Compose mais absents du nouveau (typiquement Redis pour les mises à jour depuis des versions anterieures a 2025.10).
Changement spécifique à la version 2025.12 : le répertoire de stockage des fichiers passe de /media à /data/media. Avant de mettre à jour, effectuez la migration suivante :
######################################## # Migration des fichiers pour 2025.12 ######################################## docker compose down mkdir -p ./data mv ./media ./data/media
12. Durcissement : check-list de sécurité
La mise en production d’un fournisseur d’identité exige une attention particulière à la sécurité. authentik concentre l’accès à l’ensemble des applications : sa compromission équivaudrait à la compromission de tous les services fédérés.
12.1 Chiffrement des communications
Toutes les communications entre les utilisateurs et authentik doivent transiter en HTTPS avec un certificat valide. il est souhaitable de configurez une redirection systématique de HTTP vers HTTPS. Si l’instance PostgreSQL est hébergée sur un serveur distant, il est aussi souhaitable d’activer TLS pour la connexion base de données. Depuis la version 2025.10, authentik exige TLS 1.3 ou l’extension Extended Master Secret pour les connexions PostgreSQL sécurisées.
12.2 Gestion des secrets
Les variables AUTHENTIK_SECRET_KEY et PG_PASS doivent être générées avec une entropie suffisante (les commandes fournies précédemment utilisent openssl rand a cet effet). On ne commite jamais ces secrets dans un dépôt de code. En environnement avancé, on utilisera les Docker secrets ou un gestionnaire de secrets (Vault, etc.).
12.3 Restriction de l’accès réseau
Que les ports 80 et 443 ouverts sur l’interface publique et encore mieux juste le port 443. Le port 9000 d’authentik et le port 5432 de PostgreSQL ne doivent jamais être accessibles depuis l’extérieur. Si possible, on restreint l’accès à l’interface d’administration (/if/admin/) par IP source ou via un VPN.
12.4 Politique MFA (Multi-Factor Authentication)
Nous activons l’authentification multi-facteur pour les comptes administrateurs au minimum, et idéalement pour tous les utilisateurs. authentik supporte TOTP (applications type Google Authenticator ou Authy), WebAuthn/FIDO2 (cles physiques, passkeys), Duo Security, et l’envoi de codes par SMS. il sera préférable également de configurer des codes de récupération pour les cas de perte du second facteur.
12.5 Socket Docker
Comme détaillé en section 8.2, nous évitons le montage direct du socket Docker. On utilisera un Docker Socket Proxy ou gérera les outposts manuellement.
12.6 Observabilité et journalisation
Authentik expose des métriques Prometheus sur l’endpoint /-/metrics/ (serveur) et sur le port 9300 (worker). On pourra intégrer ces métriques dans un système de monitoring (Grafana, Datadog, etc.) pour surveiller le nombre de taches en attente, les échecs d’authentification et l’état de santé de PostgreSQL.
13. Nouveautes de la version 2025.12
La version 2025.12, sortie en janvier 2026, apporte plusieurs évolutions notables. Le système de permissions RBAC à été profondément revu : les groupes peuvent désormais avoir plusieurs parents et héritent des rôles et permissions de tous leurs ancêtres. Les permissions ne peuvent plus être attribuées directement à un utilisateur ; elles doivent passer par un rôle.
Un système de gestion centralisée des fichiers fait également son apparition. Les icônes, arrière-plans de flux, avatars et logos sont désormais gères depuis « Customization > Files » dans l’interface d’administration, avec possibilité de stocker ces fichiers sur un backend S3.
Cette version introduit la gestion des Endpoint Devices (Windows, macOS, Linux), permettant l’authentification locale avec les identifiants authentik, ainsi que l’export de données en CSV.
14. Conflits d’information identifiés et résolution
Redis requis ou non ? De nombreuses ressources en ligne (articles, tutoriels, anciens fichiers Compose) incluent encore Redis comme composant nécessaire. Cela reflète l’état des versions antérieures à 2025.10. Pour toute installation neuve ou mise à jour récente, Redis n’est plus nécessaire.
Tag :latest : certains guides recommandent d’utiliser le tag :latest pour les images Docker d’authentik. L’équipe de développement à gelé ce tag à la version 2025.2 et recommande l’utilisation d’un tag de version explicite (ex: :2025.12.1) pour éviter les mises à jour involontaires.
Répertoire /media vs /data : à partir de la version 2025.12, le point de montage passe de /media à /data. Les guides antérieurs à cette version font référence à /media, ce qui reste valide pour les versions 2025.10 et antérieures.
15. Points d’attention
DNS et HTTPS : le FQDN configuré pour authentik doit correspondre exactement à l’URL publique utilisée dans les redirections OIDC et les assertions SAML. Toute incohérence entre l’issuer, les callback URLs et le certificat TLS provoquera des échecs d’authentification.
Claim email_verified : depuis la version 2025.10, le scope mapping par défaut retourne email_verified: false au lieu de true. Certaines applications nécessitent que cette valeur soit à true pour autoriser la connexion. Si c’est la cas, on crée un scope mapping personnalisé.
PostgreSQL : avec la suppression de Redis, PostgreSQL gère environ 50 % de connexions supplémentaires. Pour les installations à forte charge, il faudra surveiller le paramètre max_connections de PostgreSQL et envisager l’utilisation d’un pooleur de connexions (PgBouncer, PgPool).
Sauvegardes : il sera plus que nécessaire de tester le processus complet de restauration (dump PostgreSQL + fichiers). Ou une restauration de snapshot ou de backup dans le case d’une installation sur une VM (c’est un peu radical 🤣)
Outposts : les versions des outposts et du serveur authentik doivent être rigoureusement identiques. Une discordance de version provoquera des dysfonctionnements.
C’était Zérosécu, et comme je dis toujours, la cybersécurité est moins cher que gratuit.
J’apporte la plus grande attention et le plus grand soin à chaque article, mais si toutefois, si vous repérez une erreur, faites-moi signe !
Note de les droits d’auteur (images): Les visuels intégrés peuvent provenir de la documentation officiels d’Authentik, et sont utilisés à des fins d’illustration et d’analyse conformément au droit de citation.
Sources et references:
Documentation officielle authentik :
Installation Docker Compose | Architecture | Configuration (variables d’environnement) | Procedure de mise à jour | Worker et taches de fond | Haute disponibilite
Providers et integrations :
Provider OAuth2/OIDC | Provider SAML | Provider Proxy | Catalogue d’integrations
Notes de version :
Release notes 2025.10 (suppression Redis) | Release notes 2025.12 (RBAC, gestion fichiers) | Blog : « We removed Redis » | Blog : version 2025.12