Pourquoi une passerelle d’authentification en reverse proxy
Chaque outil auto-hébergé que vous ajoutez à votre VPS est une nouvelle surface d’attaque. Certains disposent d’une authentification solide (Gitea, Nextcloud), d’autres sont conçus pour des réseaux de confiance (Prometheus, Dockge, tableaux de bord internes) et ne fournissent aucune authentification. Ajouter une vérification identifiant + mot de passe à chaque application individuellement prend du temps, crée des incohérences et vous laisse quand même gérer des dizaines de bases d’identifiants distinctes.
Authelia règle le problème au niveau de l’infrastructure. Vous la configurez une seule fois — avec des règles du type « toute personne accédant à *.internal.votre-domaine.com doit valider une authentification à deux facteurs » — et votre reverse proxy applique ces règles à chaque requête, avant qu’elle n’atteigne l’application. Les applications elles-mêmes n’ont besoin d’aucune modification.
Ce qu’Authelia auto-hébergé vous apporte
- Le MFA pour n’importe quelle application : TOTP (Google Authenticator, Ente Auth, Aegis), WebAuthn/Passkeys (Touch ID, Face ID, YubiKey) et Duo push — configuré une fois, appliqué partout.
- Fournisseur OpenID Connect (OIDC) : configurez Authelia comme fournisseur d’identité pour Gitea, Nextcloud, Mattermost et toute application compatible OIDC. Une seule connexion, toutes vos applications.
- Contrôle d’accès fin : définissez des politiques par domaine, sous-domaine, chemin d’URL, réseau IP ou groupe d’utilisateurs — autoriser, refuser, un facteur ou deux facteurs.
- Indépendant du reverse proxy : intégration en copier-coller avec Nginx, Caddy, Traefik, HAProxy et Envoy via une seule directive
forward_auth. - Moins de 30 Mo de RAM au repos — à ajouter sur n’importe quel VPS existant sans impacter les charges de travail en cours.
- Backend utilisateurs basé sur fichier ou sur LDAP — commencez simple, montez en charge plus tard.
Prérequis
Un VPS avec au moins 1 vCPU et 512 Mo de RAM (1 Go recommandé) sous Ubuntu 22.04 ou Debian 12, avec Docker et Docker Compose v2 installés. Un nom de domaine pointant vers le VPS est requis — les cookies de session et les callbacks OIDC d’Authelia doivent être rattachés à un FQDN en bonne et due forme, et le HTTPS via Let’s Encrypt est obligatoire. Si votre VPS fait déjà tourner Caddy ou Nginx comme reverse proxy, Authelia vient s’y greffer.
Déployer Authelia avec Docker Compose
Rédiger le fichier Compose
Créez /opt/authelia/compose.yaml. La stack compte deux services : authelia/authelia:4.39.20 et redis:7-alpine. Authelia stocke les données de session dans Redis et l’état applicatif (base de données SQLite, journal de notifications) dans un volume Docker nommé, monté sur /data. Deux montages bind depuis ./ fournissent le fichier de configuration et la base des utilisateurs — ils sont générés par le job de provisioning de ServOrbit.
Créer configuration.yml
Authelia lit sa configuration depuis /config/configuration.yml (monté en bind depuis l’hôte). La configuration minimale définit l’adresse du serveur (tcp://:9091), le backend d’authentification par fichier (/config/users.yml), le domaine et le secret de session, le chemin de stockage SQLite, l’hôte Redis pour les sessions et les règles de contrôle d’accès. Commencez avec default_policy: deny et ajoutez des règles one_factor pour vos domaines.
Créer la base des utilisateurs
Le backend fichier d’Authelia lit un fichier YAML contenant les noms d’utilisateur, les mots de passe hachés en bcrypt, les e-mails et les groupes. Générez un hash pour votre mot de passe administrateur avec : docker run --rm authelia/authelia:4.39.20 authelia crypto hash generate bcrypt. Collez la sortie dans users.yml. Sur ServOrbit, le job de provisioning écrit ce fichier automatiquement, avec un mot de passe généré affiché dans la sortie du job.
Démarrer la stack et vérifier
Lancez docker compose up -d dans /opt/authelia. Vérifiez que les deux conteneurs sont sains avec docker compose ps. Authelia expose un endpoint de santé sur GET /api/health — curl -s http://localhost:9091/api/health doit renvoyer {"status":"OK"}. Le portail de connexion est alors disponible sur https://auth.votre-domaine.com une fois votre reverse proxy configuré.
Ajouter la directive forward_auth à votre proxy
Pour Caddy, ajoutez forward_auth authelia:9091 aux blocs de site que vous voulez protéger, en référençant le nom de service du conteneur Authelia si les deux sont sur le même réseau Docker. Pour Nginx, ajoutez auth_request /authelia; et le bloc location correspondant. La documentation d’Authelia fournit des extraits en copier-coller pour chaque proxy majeur. Rechargez la configuration de votre proxy — chaque application protégée exige désormais une connexion via Authelia.
Enregistrer votre appareil MFA
Connectez-vous au portail Authelia sur https://auth.votre-domaine.com avec vos identifiants administrateur. Vous serez invité à enregistrer un second facteur. Ouvrez votre application TOTP (Google Authenticator, Ente Auth ou Aegis), scannez le QR code et confirmez. Pour les passkeys (WebAuthn), cliquez sur « Security Key or Passkey » et suivez l’invite de votre navigateur — Face ID, Touch ID et les YubiKey fonctionnent tous. Les connexions suivantes exigeront votre mot de passe ainsi que le facteur enregistré.
Se connecter la première fois
Ouvrez l'adresse de votre portail : Authelia demande un identifiant et un mot de passe. Saisissez « admin » et le mot de passe qui vous a été transmis (retrouvable dans la section Applications de votre espace client), puis enregistrez immédiatement votre application d'authentification (TOTP) ou votre clé d'accès — c'est le second facteur qui protégera ensuite tout ce que vous placerez derrière ce portail.
Utiliser Authelia comme fournisseur OIDC pour un vrai SSO
Une fois Authelia en marche, vous pouvez enregistrer vos autres applications auto-hébergées en tant que clients OIDC. Dans configuration.yml, ajoutez un bloc identity_providers.oidc listant, pour chaque application, le client ID, le secret et les redirect URIs. Configurez ensuite l’application (Gitea, Nextcloud, Grafana…) pour qu’elle utilise Authelia comme fournisseur OIDC. Les utilisateurs s’authentifient une seule fois sur auth.votre-domaine.com et sont redirigés silencieusement vers chaque application connectée en OIDC — plus d’invites de connexion séparées, une seule session pour toute votre stack.
Règles de contrôle d’accès
La section de contrôle d’accès d’Authelia est l’endroit où vous définissez qui peut accéder à quoi. Les règles sont évaluées de haut en bas ; la première correspondance l’emporte. Une configuration de production minimale peut laisser passer vos applications exposées publiquement, exiger un facteur pour les outils internes courants et imposer deux facteurs pour tout ce qui est sensible (panneaux d’administration, gestionnaires de secrets, bases de données). Utilisez le champ groups dans users.yml pour distinguer les administrateurs des utilisateurs ordinaires et appliquer des politiques plus strictes aux membres du groupe admin.
