Comprendre authentik : applications, providers, flows et outposts

authentik est un fournisseur d’identité (IdP) open source qui centralise l’authentification, l’autorisation et le provisioning des utilisateurs. Ce guide pose les bases conceptuelles : les objets principaux, la logique modulaire flows/stages/policies, les modes d’intégration et les limites. Aucune installation ici — le guide Docker Compose prend le relais ensuite.

Le problème à résoudre

La multiplication des comptes locaux

Dans un environnement DevOps typique, chaque outil gère ses propres comptes : Grafana a ses utilisateurs, GitLab a les siens, Portainer aussi. Quand un collaborateur rejoint l’équipe, il faut créer 5 ou 10 comptes. Quand il part, il faut tous les révoquer — et on en oublie toujours.

C’est comme distribuer un trousseau de clés différent pour chaque pièce d’un bâtiment, sans registre central. À 3 utilisateurs, c’est gérable. À 30, c’est un cauchemar opérationnel et un risque de sécurité.

Les limites des authentifications disparates

Même avec un annuaire LDAP ou Active Directory, le problème reste partiel :

Pas de SSO — l’utilisateur tape son mot de passe dans chaque application
Pas de MFA centralisé — certaines applications le supportent, d’autres non
Pas de provisioning automatique — les comptes sont créés manuellement
Pas de politique d’accès unifiée — chaque application définit ses propres règles

Le résultat : des comptes orphelins, des mots de passe réutilisés, des accès trop larges et aucune visibilité sur qui accède à quoi.

Pourquoi l’IAM devient une brique centrale

Un fournisseur d’identité (IdP) résout ces problèmes en devenant le point unique d’authentification. L’utilisateur se connecte une fois, et l’IdP délivre des tokens aux applications qui en ont besoin. L’administrateur gère les utilisateurs, les groupes et les politiques d’accès depuis une seule interface.

authentik est conçu pour remplir exactement ce rôle, en couvrant un périmètre plus large que la plupart des solutions open source : SSO, fédération, proxy d’accès, provisioning SCIM et annuaire LDAP — dans un seul produit.

Ce qu’est authentik

Un fournisseur d’identité open source et modulaire

authentik est un Identity Provider (IdP) qui centralise :

L’authentification — vérifier qui est l’utilisateur (SSO, MFA, social login)
L’autorisation — décider ce qu’il peut faire (politiques, groupes, rôles)
Le provisioning — créer et synchroniser les comptes dans les applications cibles
La fédération — consommer des identités venant d’autres systèmes (LDAP, Active Directory, autre IdP)

Le projet est développé en Python (Django) côté serveur et TypeScript (lit-html) côté interface. Il est distribué sous licence MIT et hébergé sur GitHub.

Les usages couverts

Usage	Comment authentik le gère
SSO pour applications web	Provider OIDC ou SAML
Portail d’accès centralisé	Interface « My Applications »
Proxy d’accès pour apps non compatibles	Proxy provider + outpost
Annuaire LDAP	LDAP provider + outpost
Provisioning automatique	SCIM provider
Fédération avec Active Directory	Source LDAP
Social login (Google, GitHub…)	Source OAuth
MFA (TOTP, WebAuthn, codes de secours)	Stages d’authentification

Ce qu’authentik ne remplace pas

authentik n’est pas :

Un gestionnaire de secrets (pour cela, utilisez HashiCorp Vault ou un outil équivalent)
Un bastion SSH (pour cela, regardez Teleport ou un outil similaire)
Un reverse proxy à haute performance — le proxy provider d’authentik est fait pour le contrôle d’accès, pas pour le load balancing
Un moteur d’autorisation fine-grained comme OPA ou Cedar — authentik gère l’autorisation à l’entrée (qui a le droit d’accéder), pas les permissions internes à l’application

Les objets principaux d’authentik

authentik organise sa configuration autour de quelques objets clés. Comprendre leur rôle évite de se perdre dans l’interface d’administration.

Les applications

Une application dans authentik représente un service que vous voulez protéger. C’est l’objet visible par les utilisateurs dans le portail « My Applications ». Chaque application est reliée à un provider qui définit comment l’authentification fonctionne pour ce service.

Concrètement : si vous avez Grafana, GitLab et un wiki interne, vous créerez trois applications dans authentik.

Les providers

Un provider définit le protocole et les paramètres techniques pour connecter une application à authentik. C’est la partie technique de l’intégration.

Type de provider	Protocole	Cas d’usage typique
OAuth2/OIDC	OpenID Connect	Applications web modernes
SAML	SAML 2.0	Applications d’entreprise, legacy
Proxy	Forward Auth / Reverse Proxy	Applications sans support OIDC/SAML
LDAP	LDAP v3	Applications qui ne parlent que LDAP
SCIM	SCIM 2.0	Provisioning automatique de comptes
RADIUS	RADIUS	VPN, Wi-Fi, équipements réseau

L’astuce pour démarrer : utilisez « Create with Provider » dans l’interface pour créer l’application et le provider en une seule étape.

Les sources

Une source est le symétrique d’un provider : au lieu de fournir des identités vers une application, authentik consomme des identités depuis un système externe.

Type de source	Système externe	Ce qu’authentik récupère
LDAP	Active Directory, OpenLDAP	Utilisateurs et groupes
OAuth	Google, GitHub, Azure AD	Identité via social login
SAML	Un autre IdP SAML	Identité fédérée
SCIM	Un système RH ou un autre IdP	Utilisateurs provisionnés

Les outposts

Un outpost est un composant déployé séparément d’authentik, qui exécute une fonction spécifique sur le réseau. C’est le bras armé d’authentik à l’extérieur de la plateforme centrale.

Trois types d’outposts existent :

Proxy outpost — intercepte le trafic HTTP et applique l’authentification pour les applications non compatibles OIDC/SAML. Fonctionne avec Nginx, Traefik ou Caddy via le mécanisme Forward Auth.
LDAP outpost — expose un serveur LDAP que les applications legacy peuvent interroger (bind, search). Les identités viennent d’authentik.
RADIUS outpost — fournit un serveur RADIUS pour les VPN et équipements réseau.

Chaque outpost se connecte à authentik via une API et reçoit sa configuration automatiquement. Vous pouvez déployer les outposts en tant que conteneurs Docker ou pods Kubernetes.

Le cœur du moteur : flows, stages et policies

C’est la partie d’authentik qui déroute le plus au premier contact, et c’est aussi la plus puissante. Là où Keycloak utilise des « Authentication Flows » avec des exécuteurs configurés via l’interface, authentik propose un système encore plus modulaire.

Ce qu’est un flow

Un flow est un parcours que l’utilisateur traverse pour accomplir une action. Par exemple : se connecter, s’enrôler, récupérer son mot de passe, donner son consentement.

Chaque flow a une désignation qui définit son type :

Désignation	Objectif
`authentication`	Connexion d’un utilisateur
`authorization`	Consentement avant d’accéder à une application
`enrollment`	Inscription d’un nouvel utilisateur
`invalidation`	Déconnexion
`recovery`	Récupération de mot de passe
`stage_configuration`	Configuration d’un factor MFA
`unenrollment`	Suppression de compte

Le rôle des stages

Un stage est une étape dans un flow. Chaque stage représente une action concrète que le système demande à l’utilisateur ou exécute en arrière-plan.

Exemples de stages :

Stage	Ce qu’il fait
Identification	Demande le nom d’utilisateur ou l’email
Password	Vérifie le mot de passe
Authenticator Validate	Demande le code MFA (TOTP, WebAuthn…)
Authenticator TOTP Setup	Enrôle un nouvel appareil TOTP
Email	Envoie un email de confirmation
Consent	Demande le consentement de l’utilisateur
User Write	Crée ou met à jour l’utilisateur en base
User Login	Crée la session utilisateur
Deny	Refuse l’accès

Un flow de connexion typique enchaîne : Identification → Password → Authenticator Validate → User Login. Si l’utilisateur n’a pas encore de MFA configuré, un stage de setup peut s’insérer automatiquement.

Le rôle des policies

Une policy est une condition qui s’évalue à vrai ou faux. Les policies se rattachent aux stages (ou directement aux flows) pour décider si un stage doit s’exécuter ou être sauté.

Type de policy	Ce qu’elle évalue
Expression	Code Python personnalisé
Password	Complexité du mot de passe
Reputation	Score de réputation (IP, identifiant)
Event Matcher	Correspondance avec un événement

Par exemple, une policy d’expression peut vérifier si l’utilisateur appartient à un groupe « admins » et, si oui, exiger un second facteur d’authentification. Sinon, le stage MFA est sauté.

Comment ces éléments travaillent ensemble

Le mécanisme est simple une fois qu’on le visualise :

L’utilisateur déclenche un flow (il clique « Se connecter »)
authentik parcourt les stages du flow dans l’ordre défini
Avant chaque stage, les policies rattachées sont évaluées
Si toutes les policies passent → le stage s’exécute
Si une policy échoue → le stage est sauté (ou le flow est interrompu)
Quand tous les stages sont passés → le flow est terminé

C’est cette mécanique qui rend authentik très flexible : vous pouvez construire des parcours d’authentification conditionnels sans écrire de code dans l’application.

Comment authentik construit un parcours d’authentification

Pour rendre la mécanique concrète, suivons un scénario pas à pas. Un utilisateur clique sur « Grafana » dans le portail authentik.

Étape 1 — Redirection. Grafana est configurée comme application avec un provider OIDC. Grafana redirige l’utilisateur vers authentik avec une requête d’autorisation OIDC.

Étape 2 — Flow d’authentification. authentik déclenche le flow default-authentication-flow. Le premier stage demande le nom d’utilisateur ou l’email (Identification).

Étape 3 — Mot de passe. Le stage Password vérifie les credentials. Si l’utilisateur a un mot de passe local, il est vérifié. Si l’utilisateur vient d’une source LDAP, authentik fait un bind LDAP en arrière-plan.

Étape 4 — MFA conditionnel. Une policy vérifie si l’utilisateur appartient au groupe « mfa-required ». Si oui, le stage Authenticator Validate demande un code TOTP ou une clé WebAuthn. Sinon, ce stage est sauté.

Étape 5 — Session. Le stage User Login crée la session. L’utilisateur est authentifié.

Étape 6 — Consentement. authentik vérifie les scopes demandés par Grafana. Un stage de consentement peut demander à l’utilisateur d’accepter le partage de son email et de ses groupes.

Étape 7 — Retour. authentik redirige l’utilisateur vers Grafana avec un code d’autorisation. Grafana l’échange contre un token et connecte l’utilisateur.

Tout cela est configurable : vous pouvez changer l’ordre des stages, ajouter des conditions, insérer un captcha, exiger un email de vérification, ou rediriger vers un autre flow.

Les objets visibles par les utilisateurs

Le portail « My Applications »

Les utilisateurs finaux ne voient pas l’interface d’administration d’authentik. Ils accèdent à un portail qui liste les applications auxquelles ils ont droit. Ce portail est personnalisable : nom, logo, thème et liens.

Chaque application du portail est cliquable et redirige vers le service protégé — l’authentification est transparente grâce au SSO.

Les marques (brands)

authentik supporte les brands (marques) : vous pouvez personnaliser l’apparence du portail et des pages de connexion par domaine. C’est utile si vous hébergez plusieurs organisations ou projets sur la même instance.

Comparaison rapide avec Keycloak

Les deux outils se chevauchent, mais leur philosophie diffère :

Critère	authentik	Keycloak
Langage	Python (Django)	Java (Quarkus)
Licence	MIT	Apache 2.0
Proxy d’accès intégré	Oui (proxy provider + outpost)	Non (nécessite un composant externe)
Annuaire LDAP intégré	Oui (LDAP outpost)	Non (consomme LDAP, ne l’expose pas)
SCIM provider	Oui	Non natif (extensions)
Flows personnalisables	Flows / stages / policies	Authentication Flows / Executions
Interface d’administration	Moderne (lit-html)	Classique (React depuis v24+)
Maturité	Plus récent (2020)	Très mature (2014, Red Hat)
Consommation mémoire	~500 Mo	~700 Mo–1 Go
Écosystème	Communauté en croissance	Écosystème large, support Red Hat

authentik est souvent préféré pour les déploiements de taille moyenne, les homelabs et les projets qui ont besoin du proxy provider intégré. Keycloak reste le choix de référence pour les grandes organisations avec des besoins de fédération complexes et un besoin de support commercial.

Dans quels cas utiliser authentik

Cas favorables

SSO pour un ensemble d’applications web — c’est le cas d’usage principal. OIDC pour les apps modernes, SAML pour les apps d’entreprise.
Portail d’accès centralisé — le portail « My Applications » offre un point d’entrée unique. Les utilisateurs voient uniquement les applications auxquelles ils ont droit.
Proxy d’accès pour applications non compatibles — le proxy provider évite de modifier les applications existantes. C’est un gros avantage face à Keycloak qui ne propose pas cette fonctionnalité nativement.
Provisioning automatisé — avec SCIM, authentik crée et synchronise les comptes dans les applications cibles. Moins de comptes orphelins, moins de travail manuel.
Homelab ou infrastructure de taille moyenne — l’installation Docker Compose est simple, la consommation de ressources raisonnable.

Cas moins adaptés

Grande organisation avec support commercial obligatoire — Keycloak bénéficie du support Red Hat (SSO). authentik propose une édition Enterprise, mais l’écosystème de support est plus restreint.
Besoin de conformité très spécifique (FIPS, certification Common Criteria) — Keycloak est plus avancé sur ce terrain.
Infrastructure sans conteneurs — authentik est distribué exclusivement en images Docker. Pas d’installation bare metal officielle.

À retenir

authentik est un IdP complet — SSO, fédération, proxy, LDAP, SCIM et MFA dans un seul produit
Applications + Providers — chaque service protégé est une application, reliée à un provider qui définit le protocole
Sources ≠ Providers — un provider fournit des identités vers une app, une source consomme des identités depuis un système externe
Flows → Stages → Policies — le cœur modulaire d’authentik. Les flows définissent les parcours, les stages les étapes, les policies les conditions
Les outposts étendent authentik — proxy, LDAP et RADIUS sont déployés séparément, reliés par API
Les flows par défaut suffisent pour commencer — ne personnalisez que quand un besoin concret l’exige

Prochaines étapes

Installer authentik avec Docker Compose Déployer authentik, PostgreSQL et Redis en 10 minutes pour un premier lab fonctionnel.

Fondamentaux IAM Revoir les bases : authentification, autorisation, protocoles et modèles d'accès.

OpenID Connect Comprendre le protocole OIDC avant de configurer un provider dans authentik.

Keycloak : concepts et architecture Comparer avec Keycloak pour choisir l'IdP le plus adapté à votre contexte.