Une stack d'applications internes derrière un reverse proxy : un dashboard de monitoring, une interface d'admin, un outil métier maison. Aucun n'a d'authentification sérieuse, certains n'en ont aucune. Les exposer tels quels, c'est ouvrir la porte. Ajouter un login maison à chacun, c'est trois implémentations d'auth à maintenir et à auditer, chacune avec ses trous.
Authelia règle ça par le haut. Un portail unique qui s'intercale devant toutes les apps via le mécanisme de forward-auth du reverse proxy. SSO et MFA homogènes, sans toucher au code des applications protégées. Léger, en Go, self-hosted.
Le mécanisme forward-auth
Le reverse proxy (Nginx, Traefik, Caddy, HAProxy, Envoy) délègue l'autorisation de chaque requête à Authelia avant de la laisser passer. Concrètement, pour chaque requête entrante vers une app protégée, le proxy émet une sous-requête vers l'endpoint d'Authelia, /api/authz/forward-auth. Authelia répond : autorisé, ou refusé avec redirection vers le portail de login.
Le flux : la requête arrive sur le proxy. Le proxy interroge Authelia. Si la session est valide et la politique satisfaite, Authelia répond 200, le proxy laisse passer vers l'app. Sinon, Authelia répond 401 et le proxy redirige l'utilisateur vers le portail de connexion. Une fois authentifié, l'utilisateur revient, la session est posée, les requêtes suivantes passent.
L'app protégée ne reçoit que des requêtes déjà authentifiées. Elle n'a aucune logique d'auth, elle ignore qu'Authelia existe. Authelia peut même injecter l'identité de l'utilisateur dans des en-têtes, que l'app consomme si elle sait le faire. Côté ops, ça donne une couche d'authentification posée devant n'importe quoi, sans modifier l'applicatif. Ce mécanisme est le même que celui décrit pour le reverse proxy Nginx avancé, poussé jusqu'à la délégation d'auth.
Les facteurs : du mot de passe aux passkeys
Authelia gère plusieurs facteurs d'authentification :
- Mot de passe (premier facteur), avec backend fichier ou LDAP.
- TOTP, les codes à usage unique des applications type Google Authenticator, Authy, 1Password.
- WebAuthn et passkeys, les clés matérielles type YubiKey et l'authentification sans mot de passe.
- Duo, les notifications push mobiles.
Les passkeys méritent l'attention : Authelia gère l'authentification sans mot de passe. Plutôt que mot de passe plus second facteur, l'utilisateur s'authentifie directement avec une passkey, plus résistante au phishing qu'un TOTP. Pour des accès sensibles, c'est le bon défaut en 2026.
Politiques d'accès par domaine et ressource
C'est le cœur de la valeur. Authelia applique des règles d'accès évaluées dans l'ordre, qui décident pour chaque ressource quel niveau d'authentification est requis. Une règle matche sur le domaine, sur un chemin (expression régulière), sur l'appartenance à un groupe, et applique une politique.
Les politiques vont de bypass (pas d'auth, pour une ressource publique) à one_factor (mot de passe seul) jusqu'à two_factor, le niveau le plus élevé, qui exige un second facteur. On exige du two_factor sur l'interface d'admin, du one_factor sur le dashboard interne, et on laisse passer une page de statut publique. Le tout déclaré centralement, appliqué uniformément, sans toucher aux apps.
La règle qu'on applique : two_factor sur tout ce qui touche à l'administration ou aux données sensibles, point. Le mot de passe seul devant une interface d'admin exposée ne tient pas. Et l'ordre des règles compte : Authelia prend la première qui matche, une règle trop large placée en haut court-circuite les règles fines en dessous. Le piège classique est une règle bypass mal placée qui ouvre par accident une ressource censée être protégée.
Backends et sessions
Pour l'identité, deux backends. Le backend fichier (un YAML d'utilisateurs avec mots de passe hashés) suffit pour un petit périmètre, quelques comptes, pas d'annuaire. Le backend LDAP branche Authelia sur un annuaire existant (OpenLDAP, Active Directory), et c'est le bon choix dès qu'il y a un référentiel d'identité à respecter.
Pour les sessions, attention au défaut. Authelia stocke les sessions en mémoire par défaut : à chaque redémarrage, toutes les sessions sont perdues, les utilisateurs doivent se réauthentifier. Acceptable sur un nœud unique de test, pas en prod. Le backend Redis fait persister les sessions et rend Authelia stateless, donc déployable en plusieurs instances derrière un load balancer pour la haute disponibilité. La règle : Redis dès qu'on vise de la résilience ou plusieurs instances. Mémoire seulement pour un mono-nœud sans exigence de continuité.
Authelia ou Keycloak / Authentik
La question revient à chaque projet. Authelia, Keycloak et Authentik ne jouent pas le même rôle.
Authelia est un serveur d'authentification et un portail, taillé pour le forward-auth devant un reverse proxy. Écrit en Go, son conteneur pèse sous 20 Mo et la consommation mémoire reste typiquement sous 30 Mo, sous 100 Mo même en charge. C'est l'argument poids lourd inversé : on pose une couche d'auth complète pour le coût mémoire d'un service mineur.
Keycloak est un IdP complet OIDC et SAML, avec fédération d'identités, brokering, une administration riche. Il consomme un minimum incompressible de l'ordre de 400 à 500 Mo de RAM même avec une poignée d'utilisateurs. Authentik se place entre les deux, plus complet qu'Authelia, plus lourd, moins qu'un Keycloak.
| Critère | Authelia | Keycloak / Authentik |
| Rôle | Portail auth, forward-auth | IdP complet OIDC / SAML |
| Empreinte mémoire | Sous 100 Mo | 400 à 500 Mo (Keycloak) |
| Forward-auth | Cœur du produit | Possible, pas le cœur |
| Fédération SAML, brokering | Limité | Complet |
| OIDC provider | Oui (intégré) | Oui (cas d'usage central) |
Authelia a d'ailleurs intégré un provider OpenID Connect, certifié OpenID, ce qui lui permet de servir d'IdP pour des applications qui parlent OIDC nativement, en plus du forward-auth. Le périmètre s'élargit, mais le centre de gravité reste le forward-auth.
Le verdict ops : pour protéger vite un ensemble d'applications derrière un reverse proxy avec du SSO et du MFA homogènes, sans annuaire fédéré à fédérer ni SAML, Authelia est le bon outil. Léger, ciblé, il fait exactement ça. Dès qu'il faut un IdP fédéré complet, du brokering d'identités, du SAML vers des fournisseurs externes, on passe sur Keycloak ou Authentik. La question à trancher d'abord : a-t-on besoin de fédérer des identités, ou juste de mettre une couche d'auth devant des apps ? Le second cas, c'est Authelia.
Devant des applications exposées, le même réflexe vaut pour les accès d'administration. Un bastion SSH avec MFA ferme l'accès aux serveurs, Authelia ferme l'accès aux interfaces web. Les deux relèvent de la même logique : pas d'accès sans second facteur sur ce qui compte.
Poser Authelia devant une stack d'applications, écrire les règles d'accès sans laisser de trou, brancher LDAP et Redis pour la HA, valider que rien ne passe sans le bon niveau d'auth, c'est un chantier qui se cadre et se teste. On déploie et on opère ce genre de couche d'authentification sur les infras qu'on gère. Si vos applications internes sont exposées derrière un reverse proxy sans MFA, on peut poser le SSO et durcir les accès.
Sources
- Authelia - Proxies integration : mécanisme forward-auth, endpoint /api/authz/forward-auth, proxies supportés (Nginx, Traefik, Caddy, HAProxy, Envoy).
- Authelia - Access Control configuration : règles d'accès, politiques bypass/one_factor/two_factor, ordre d'évaluation.
- Authelia - Site officiel : facteurs (TOTP, WebAuthn, passkeys, Duo), provider OIDC certifié OpenID.
- authelia/authelia (GitHub) : portail SSO et MFA, provider OpenID Connect certifié, backends et sessions.
- Comparatif Authentik / Authelia / Keycloak 2026 : empreinte mémoire et positionnement des trois solutions.
