Héberger Authelia sur un VPS : MFA et SSO pour toute la stack

Sans passerelle centralisée, chaque service gère son propre login : Grafana a sa base d'utilisateurs, Nextcloud la sienne, Portainer la sienne. Résultat : des mots de passe différents partout, pas de MFA cohérent, et une surface d'attaque démultipliée. Authelia résout ce problème en s'intercalant dans le flux HTTP : votre reverse proxy (Nginx, Traefik, Caddy) lui soumet chaque requête avant de la relayer, et Authelia décide — selon l'identité, le groupe, le chemin demandé et le niveau de MFA requis — si la requête doit passer. L'application protégée ne voit qu'une requête authentifiée avec des en-têtes d'identité injectés (Remote-User, Remote-Groups). Elle n'a pas besoin de gérer l'authentification elle-même.

Avant de déployer Authelia, vérifiez que votre environnement est prêt. Vous avez besoin d'un VPS sous Linux avec Docker et Docker Compose installés, d'un reverse proxy déjà en place (Traefik v2/v3 ou Nginx), d'un nom de domaine avec un certificat TLS valide (Let's Encrypt recommandé), et d'une instance Redis accessible par Authelia pour stocker les sessions (obligatoire en production pour la persistance et la scalabilité). Pour le stockage des utilisateurs, vous pouvez commencer avec un fichier YAML local ou brancher un serveur LDAP comme LLDAP. Authelia nécessite également une clé JWT, une clé de chiffrement de session et un secret OIDC si vous activez ce mode : générez-les avec openssl rand -hex 32.

La section access_control est le cœur de la logique d'Authelia. Depuis v4.37, les politiques ont été refondues. Voici des exemples représentatifs. Pour un accès public sans auth : {domain: 'status.mondomaine.com', policy: bypass}. Pour un accès MFA fort réservé aux admins : {domain: 'portainer.mondomaine.com', subject: 'group:admins', policy: two_factor}. Pour un chemin d'API sans auth (webhooks) : {domain: 'n8n.mondomaine.com', resources: ['^/webhook/.*'], policy: bypass}. Pour le reste de N8N en MFA simple : {domain: 'n8n.mondomaine.com', policy: one_factor}. La règle default_policy: deny garantit que tout ce qui n'est pas explicitement listé est bloqué. L'ordre des règles compte : la première règle qui correspond s'applique. Le champ subject accepte user:alice, group:admins, ou une liste combinée.

Authelia supporte trois méthodes de second facteur, chacune avec ses avantages.

TOTP (Time-based One-Time Password) est la méthode la plus universelle : l'utilisateur scanne un QR code avec une app comme Aegis (Android), Raivo (iOS) ou Bitwarden Authenticator. Un code à 6 chiffres change toutes les 30 secondes. Simple à déployer, compatible avec tous les appareils, mais vulnérable au phishing si le code est intercepté en transit.

WebAuthn/passkey est la méthode la plus robuste, supportée nativement par Authelia depuis v4.36. L'utilisateur enregistre une clé matérielle (YubiKey, Nitrokey) ou un authentificateur de plateforme (Touch ID sur macOS, Windows Hello, Face ID sur iOS). La cryptographie à clé publique rend le phishing impossible : la clé privée ne quitte jamais l'appareil. Pour optimiser la requête GSC « authelia passkey », notez qu'Authelia implémente la spec WebAuthn Level 2 complète, ce qui inclut les passkeys synchronisées (via iCloud Keychain ou Google Password Manager) en plus des clés matérielles.

Duo délègue le second facteur au service cloud Duo Security : push mobile, SMS ou appel téléphonique. Pratique pour les équipes qui utilisent déjà Duo, mais introduit une dépendance à un service tiers.

Pour la plupart des stacks auto-hébergées, la combinaison recommandée est TOTP comme méthode de base et WebAuthn comme méthode préférée pour les utilisateurs qui ont une YubiKey ou un appareil Apple/Windows récent.

Le backend fichier (users_database.yml) convient à un utilisateur ou une petite famille, mais devient difficile à gérer au-delà de 5-10 utilisateurs. LLDAP (Light LDAP) est une implémentation LDAP légère écrite en Rust, avec une interface web simple, qui s'intègre parfaitement avec Authelia.

Déployez LLDAP en ajoutant son service à votre docker-compose.yml avec les variables LLDAP_JWT_SECRET et LLDAP_LDAP_BASE_DN (ex : dc=mondomaine,dc=com). Créez vos groupes dans l'interface LLDAP (admins, users, devops…), puis modifiez votre configuration.yml pour passer du backend file au backend ldap : définissez authentication_backend.ldap.url, base_dn, users_filter ((&(uid={input})(objectClass=person))), groups_filter, user (le compte service LLDAP) et password.

Attention au breaking change v4.35 : le champ s'appelait authentification_backend (avec une faute) avant v4.35 et a été corrigé en authentication_backend. Vérifiez votre configuration si vous migrez depuis une version antérieure.

Une fois LLDAP configuré, les groupes LDAP remontent automatiquement dans les règles access_control via subject: 'group:admins', et dans les claims OIDC via le scope groups.

Authelia suit un versionnage sémantique strict et documente ses breaking changes par version. Voici les changements notables à connaître pour migrer proprement.

v4.34 : le fournisseur OIDC passe en production. Si vous l'utilisiez en mode expérimental, certaines options ont changé de nom.

v4.35 : correction de la faute de frappe authentification_backend → authentication_backend. Toute configuration utilisant l'ancien nom doit être mise à jour avant de passer à v4.35+, sinon Authelia refuse de démarrer avec une erreur de validation de configuration.

v4.37 : refonte des politiques access_control. La syntaxe des règles a évolué pour être plus explicite. Consultez le changelog officiel avant de mettre à jour depuis v4.36 ou antérieur.

v4.38.x (version actuelle) : stabilisation, pas de breaking change majeur depuis v4.37.

Procédure de mise à jour recommandée : (1) lisez le changelog depuis votre version actuelle ; (2) sauvegardez /opt/authelia/config/ et /opt/authelia/data/ ; (3) testez la nouvelle configuration avec docker run --rm -v /opt/authelia/config:/config authelia/authelia:4.38.x authelia validate-config avant de redémarrer ; (4) mettez à jour le tag dans docker-compose.yml et relancez. La commande validate-config détecte les erreurs de schéma avant le déploiement.

Authelia expose ses métriques Prometheus sur /metrics (port configurable, par défaut 9959). Activez-les dans configuration.yml avec telemetry.metrics.enabled: true et telemetry.metrics.address: 'tcp://0.0.0.0:9959'. Ne rendez pas ce port public : exposez-le uniquement à votre stack de monitoring interne.

Les métriques clés à surveiller : authelia_authn_requests_total (total des tentatives d'authentification, labellisées par succès/échec), authelia_authn_duration_seconds (latence d'authentification), et les métriques Redis sous-jacentes pour la santé des sessions.

Pour les logs, Authelia supporte le format JSON structuré (log.format: json) idéal pour l'ingestion dans Loki ou un SIEM. Définissez log.level: info en production (évitez debug qui logue les headers complets). Les logs d'authentification incluent l'IP source, le nom d'utilisateur, le service cible et le résultat — précieux pour détecter les tentatives de force brute.

Dans Grafana, créez une alerte sur un taux d'échec d'authentification anormal (ex : plus de 10 échecs en 5 minutes sur le même utilisateur) pour détecter les attaques par dictionnaire avant qu'elles aboutissent.

Redirect loop infini. L'utilisateur est renvoyé en boucle entre le service et le portail Authelia sans jamais se connecter. Cause la plus fréquente : session.domain ne correspond pas au domaine du service. Si votre service est sur app.mondomaine.com et session.domain est autredomaine.com, le cookie de session n'est jamais renvoyé. Vérifiez aussi que le middleware forwardAuth est bien appliqué et que default_redirection_url pointe vers une URL valide.

Cookie domain mismatch. Le navigateur refuse de renvoyer le cookie. Cause : session.domain doit être le domaine parent commun (mondomaine.com), pas un sous-domaine. Vérifiez avec les DevTools (onglet Application > Cookies) que le cookie authelia_session a bien le bon domaine.

Redis unreachable. Authelia démarre mais les sessions ne persistent pas, ou le log affiche Error connecting to Redis. Vérifiez que le conteneur Redis est sur le même réseau Docker qu'Authelia, que le host dans configuration.yml correspond au nom du service Docker (pas localhost), et que Redis n'est pas protégé par un mot de passe non configuré côté Authelia.

Configuration invalide au démarrage. Depuis v4.35, le schéma de configuration est strictement validé. Utilisez authelia validate-config avant tout redémarrage. Les erreurs les plus courantes : authentification_backend (vieille faute), mauvaise indentation YAML, ou champ OIDC manquant (client_secret doit être hashé avec Argon2id depuis v4.37).

MFA non proposé malgré two_factor dans les règles. Vérifiez que l'utilisateur a bien enregistré un second facteur dans son profil (https://auth.mondomaine.com). Sans appareil MFA enregistré, Authelia peut appliquer un repli sur one_factor selon votre configuration default_2fa_method.