authentik 2026.8 est sortie dans la soirée du 18 août 2026, sous le tag version/2026.8.0. Version majeure, pas correctif. Sur un fournisseur d’identité, la nuance compte : quand le SSO tombe, tout ce qui vit derrière tombe avec lui. Voici ce qui change pour l’édition communautaire, et les deux changements cassants à lire avant de tirer la nouvelle image.
La certification OpenID est le vrai fait marquant
authentik est désormais OpenID Certified™ auprès de l’OpenID Foundation. La certification couvre les profils OpenID Provider (Basic, Implicit, Hybrid, Config et Form Post OP) et les profils de déconnexion : RP-Initiated, Front-Channel et Back-Channel.
Ça ressemble à de la paperasse, jusqu’au soir où vous cherchez pourquoi un client OIDC refuse de se déconnecter proprement. Le comportement a été testé contre la spécification, pas seulement contre les applications que les mainteneurs avaient sous la main. Face à Keycloak et Authelia, c’est un argument concret.
La réécriture en Rust n’accélère rien pour l’instant
Deux composants écrits en Go passent en Rust : le point d’entrée des requêtes du serveur authentik, et l’outpost proxy. Le cœur Django n’a pas bougé. Seule la porte d’entrée a changé de langage.
Les mainteneurs sont directs sur ce que ça apporte aujourd’hui : rien. La réécriture visait une correspondance stricte avec l’ancien code, sans amélioration propre. C’est du travail préparatoire pour rapprocher le cœur Django et le proxy Rust. Si un résumé vous vend ça comme un gain de performance, il se trompe. Seul changement pratique, les health checks du serveur et du worker passent par le point d’entrée Rust.
Ce que récupère l’édition gratuite
Le user switching est l’ajout le plus visible. Plusieurs comptes authentik restent connectés dans le même navigateur, et la bascule se fait depuis le menu de compte. Un administrateur l’active en choisissant un « User switch flow » sur une marque. Comme c’est un flux authentik ordinaire, une politique peut exiger un mot de passe ou du MFA avant la bascule. Les bascules réussies sont journalisées.
Les object attributes sont des champs personnalisés que vous définissez sous Directory > Object attributes, en texte, nombre ou booléen, avec les options obligatoire, unique et validation par expression régulière. Ils couvrent les utilisateurs, les groupes, les entitlements d’application et les groupes d’accès aux appareils, et l’API applique les mêmes règles. Des définitions prêtes à l’emploi (identité, contact, adresse, Unix, employé) arrivent désactivées.
Le Dynamic Client Registration laisse les applications s’enregistrer elles-mêmes, au lieu d’obliger un admin à en fabriquer une à la main pour chacune. Le contrôle reste côté administrateur, via les bindings de politiques et des restrictions sur les types de grant, les scope mappings et la validité des jetons.
Le reste du chantier OAuth vise plus étroit. Le token exchange arrive désactivé et s’active dans les Grant Types du provider. La délégation on-behalf-of suit la RFC 8693 et s’appuie sur le claim act. L’OpenID key binding lie les jetons d’ID à une clé que le client doit prouver détenir, donc un jeton volé ne suffit plus.
Côté exploitation :
- L’option « Sync Group Parents » préserve les hiérarchies de groupes imbriqués venant d’une source LDAP.
- Les bindings de politiques, de groupes et d’utilisateurs acceptent une date d’expiration, donc les accès temporaires se nettoient seuls.
- Les poolers PostgreSQL sont supportés en mode transaction, avec une connexion directe séparée pour les opérations qui exigent une session stable.
- Plus discret : vue compacte du tableau de bord des applications, provider CAPTCHA auto-hébergeable Cap, signature Ed448, et
ForceAuthnSAML qui exige maintenant une authentification fraîche.
Deux changements cassants à traiter
La commande hash_password n’accepte plus le mot de passe en argument positionnel. Lancez-la sans argument et saisissez le mot de passe à l’invite masquée :
docker compose run --rm server hash_passwordPour l’automatisation, passez-le par l’entrée standard :
echo "$PASSWORD" | docker compose run --rm server hash_passwordLe stage WebAuthn perd son option « Prevent duplicate devices ». Elle comparait des certificats d’attestation que les fabricants partagent sur des lots de production entiers, si bien qu’acheter deux clés de sécurité ensemble pouvait faire rejeter la seconde comme un doublon. Désactivée par défaut depuis la 2026.5.4, elle ne demande aucune action à la mise à jour.
Base URL devient obligatoire en 2026.11
Un nouveau réglage système Base URL contient l’URL externe de votre instance. Il se pose sous System > Settings, par l’API, ou avec AUTHENTIK_WEB__BASE_URL à l’installation. Renseignez le schéma et l’hôte uniquement, même si authentik est servi sous un sous-chemin.
Il devient obligatoire dans authentik 2026.11, et les mainteneurs conseillent de le poser maintenant plutôt qu’au milieu d’une montée de version. En parallèle, AUTHENTIK_POSTGRESQL__CONN_OPTIONS et son équivalent réplica sont dépréciés. La 2026.8 n’ajoute aucun prérequis, et l’outillage de cycle de vie bloque désormais les sauts de version majeure non supportés avant les migrations.
Des erreurs de tâches vont apparaître après la mise à jour
Le statut des tâches suit maintenant ce que la tâche a journalisé. Avant, une tâche qui loguait une erreur mais se terminait quand même passait pour réussie, et la page System Tasks masque les tâches réussies par défaut, donc l’échec ne remontait jamais. Des échecs déjà présents chez vous depuis des semaines peuvent surgir juste après la mise à jour. C’est le reporting qui devient honnête, pas une régression.
Ce qui reste réservé à l’Enterprise
Plusieurs gros noms de cette version sont payants : le Privileged Access Management, avec des demandes d’accès soumises à approbateur et à expiration ; les comptes « Agent », qui agissent pour un utilisateur parent ; l’offboarding utilisateur planifié ; les cartes d’événements auto-hébergées pour les réseaux isolés ; et les providers WS-Federation, qui émettent des assertions SAML 1.1.
Les notes de version complètes sont sur le site de documentation d’authentik, et le build tagué sur GitHub. Notre fiche Authentik détaille la stack Compose à quatre conteneurs et la comparaison avec Keycloak et Authelia. L’outpost proxy se place derrière un reverse proxy comme Traefik.