Authelia

Le reverse proxy consulte Authelia à chaque requête

Authelia est un serveur d'authentification et d'autorisation écrit en Go, sous licence Apache-2.0, qui se branche sur le reverse proxy. Le proxy l'interroge à chaque requête, et Authelia lui répond de laisser passer, de bloquer ou de rediriger vers son portail de connexion. Comme le contenu des requêtes ne lui parvient jamais, une API REST ou GraphQL se protège comme une interface web. Une fois connecté, l'utilisateur garde un cookie de session valable sur tous les sous-domaines du domaine protégé.

Authelia est aussi fournisseur OpenID Connect pour les applications qui savent déléguer leur connexion. Il s'installe en binaire statique, en paquet .deb ou en image Docker.

Le comparatif des outils de SSO auto-hébergés range Authelia parmi les portails placés devant le reverse proxy, face aux fournisseurs d'identité complets.

Règles fines et double facteur pour applications sans comptes

• Une application sans comptes se protège depuis le proxy : ForwardAuth sur Traefik, forward_auth sur Caddy, auth_request sur NGINX. Les applications qui lisent des en-têtes reçoivent l'identité dans Remote-User, Remote-Groups, Remote-Name et Remote-Email.
• Des règles d'accès fines : sous-domaine, utilisateur, groupe, chemin, méthode HTTP ou réseau d'origine, avec un ou deux facteurs exigés selon la règle.
• Plusieurs seconds facteurs : clés de sécurité WebAuthn comme une YubiKey, codes TOTP, notifications push via Duo, et connexion sans mot de passe par passkey. Après trop d'échecs, le compte est bloqué pour un temps.

Ni inscription ni SAML, et HTTPS exigé même en essai

Authelia ne gère pas les comptes. Les utilisateurs vivent soit dans un fichier YAML qui contient leurs mots de passe hachés, soit dans un annuaire LDAP externe : OpenLDAP, FreeIPA, Active Directory ou LLDAP. La documentation le dit sans détour : Authelia n'a aucune fonction d'inscription. Avec le fichier, ajouter quelqu'un revient à l'éditer à la main, et Authelia le relit si l'option watch est active. VoidAuth, qui se branche lui aussi en ForwardAuth, gère comptes, groupes, invitations et inscriptions depuis une interface web.

La configuration se fait dans un fichier, sans console d'administration. Elle est statique et ne se règle pas par une interface web, précise la documentation ; un panneau d'administration figure sur la feuille de route.

HTTPS est obligatoire, même pour un essai. Le cookie de session ne circule que sur une connexion chiffrée, si bien que chaque application protégée par le proxy doit elle aussi passer en https. L'équipe a écarté le HTTP pour éviter les erreurs de configuration.

La documentation recommande PostgreSQL, Redis et SMTP en production. La base SQL garde les préférences, les secrets des seconds facteurs et l'historique des connexions. SQLite suffit pour un essai mais interdit de lancer plusieurs instances ; MySQL est aussi accepté. Les sessions restent en mémoire par défaut, et Redis est conseillé en production comme en haute disponibilité. Les mails de vérification partent par SMTP ; l'écriture dans un fichier est réservée aux tests. Côté ressources, le site du projet annonce une image compressée sous 20 Mo et une mémoire habituellement sous 30 Mo.

Huit reverse proxies sont pris en charge, Apache n'en fait pas partie. La matrice de compatibilité liste Traefik, Caddy, NGINX, NGINX Proxy Manager, SWAG, HAProxy, Envoy et Skipper. Apache et IIS y sont marqués non pris en charge. Sur Kubernetes, les guides couvrent ingress-nginx, Traefik, Istio et Envoy Gateway.

OpenID Connect est certifié mais reste en bêta, et SAML n'existe pas encore. Authelia porte la certification OpenID pour les profils Basic, Implicit, Hybrid, Form Post et Config OP. La feuille de route garde pourtant le fournisseur OIDC en bêta, avec des changements cassants possibles. SAML 2.0 en est encore au choix d'une bibliothèque. Une application qui ne parle que SAML demande un autre fournisseur, comme authentik, qui gère SAML en plus d'OIDC, LDAP et RADIUS.

La branche 4.39 reçoit des correctifs depuis mars 2025. La v4.39.0 date du 16 mars 2025 et la v4.39.28 du 17 septembre 2026 ; huit de ces 28 versions correctives sont sorties entre le 3 et le 17 septembre 2026. Le README avertit que le projet reste sujet à des changements cassants et conseille d'épingler un numéro de version plutôt que latest. L'équipe y indique aussi chercher des financements pour un audit de sécurité du code ou un test d'intrusion. Le chart Helm est encore en bêta.