L’univers auto-hébergé rencontre un problème aussi ancien qu’inévitable : plus vous déployez de services, plus vous gérez de identifiants. Aujourd’hui, c’est un panneau Grafana, demain Nextcloud, après-demain un wiki interne, et à la fin vous vous retrouvez avec une collection de logins qui ne s’adapte plus ni à vous… ni à votre équipe.

Dans ce contexte apparaît VoidAuth, un projet open source qui se présente comme un fournisseur d’authentification et de gestion des utilisateurs, conçu pour se placer “devant” vos applications auto-hébergées, en centralisant l’authentification et le contrôle d’accès. Son concept est simple : un portail de connexion unique, supportant OpenID Connect (OIDC), le mode ForwardAuth en tant que proxy, et des fonctionnalités modernes telles que passkeys et MFA. Tout cela avec un déploiement simple (par exemple via Docker Compose) et sans transformer votre homelab en une consultation IAM.

Ce que propose VoidAuth (en pratique)

VoidAuth se définit comme un “SSO pour votre univers auto-hébergé”. Sur le plan fonctionnel, le projet se distingue par :

• Fournisseur OIDC pour que les applications compatibles déléguent la connexion et reçoivent des jetons selon les standards.
• ForwardAuth / proxy pour protéger des services qui ne prennent pas en charge nativement l’OIDC, en tant que “couche” d’authentification devant le reverse proxy.
• Gestion des utilisateurs et groupes, avec invitations et auto-enregistrement (selon la configuration).
• Passkeys et MFA, y compris la possibilité de comptes “passkey-only”.
• Réinitialisation du mot de passe par email et modèles personnalisables (branding et messages).
• Chiffrement au repos avec une base de données Postgres ou SQLite.

Tout cela avec une promesse séduisante pour les profils techniques : le déployer rapidement, l’intégrer avec votre proxy (Caddy/Traefik/Nginx, etc.) et commencer à protéger vos services sans reconfigurer chaque login individuellement.

Un point important, que le projet lui-même reconnaît : il n’a pas encore fait l’objet d’audits et s’appuie sur des paquets tiers pour une partie de ses fonctionnalités. Cela n’invalide pas son utilité, mais il faut le traiter comme un logiciel encore jeune, à déployer avec prudence (segmentation réseau, sauvegardes, permissions minimales et supervision).

Comparatif : VoidAuth face aux “autres méthodes” classiques

Dans la pratique, le choix n’est pas souvent “VoidAuth oui ou non”, mais plutôt “qu’est-ce qui est le plus avantageux pour mon cas ?”. Voici les options les plus courantes et comment VoidAuth s’y intègre :

1) La méthode “rapide” : Basic Auth, listes d’IP en allowlist et mots de passe par app

C’est le point de départ typique. Ça fonctionne… jusqu’à ce que :

• vous ayez plusieurs utilisateurs,
• besoin de révoquer des accès sans tout casser,
• voulez MFA ou passkeys,
• ou que l’on vous demande traçabilité et cohérence.

VoidAuth l’emporte ici en centralisant les identités et en adoptant une approche consistant à “mettre une sentinelle” devant plusieurs applications avec une expérience de connexion cohérente.

2) “Annuaire + LDAP” (FreeIPA / LDAP / AD)

LDAP/AD sont très puissants, mais pas toujours conviviaux si vous cherchez simplement un SSO pour des outils web auto-hébergés. De plus, beaucoup d’applications modernes communiquent mieux via OIDC que LDAP.
VoidAuth peut être plus direct si votre objectif est SSO web et contrôle d’accès sans déployer ou maintenir un annuaire complet.

3) Authelia (léger, très utilisé dans les homelabs)

Authelia est apprécié pour sa simplicité, sa bonne intégration en “couche” devant le proxy et sa capacité à couvrir 80 % des besoins d’accès web. Il peut aussi agir comme fournisseur OIDC et est largement utilisé dans Kubernetes/homelab.
Où Va VoidAuth : dans la panoplie : portail/connexion + gestion des utilisateurs/groupes + passkeys + invitation/inscription, pour une expérience “tout-en-un” pour les administrateurs et utilisateurs.

4) Keycloak (standard en entreprise, mais plus lourd)

Keycloak est une solution IAM robuste : mature, modulaire, avec une grande compatibilité SAML/OIDC et un vaste écosystème (au prix d’une certaine complexité).
Où s’insère VoidAuth : quand vous souhaitez quelque chose de plus léger et focalisé pour protéger vos applications auto-hébergées, sans engager une implémentation “corporate” complète.

5) Authentik (très complet, entre homelab et entreprise)

Authentik est reconnu pour ses flux visuels, ses capacités en tant qu’IdP et son intégration avec de nombreuses apps. Mais il demande une courbe d’apprentissage et un certain “poids” en plateforme.
VoidAuth peut être avantageux si vous privilégiez simplicité opérationnelle et un ensemble de fonctionnalités clair pour un “SSO quotidien”.

6) SSO géré (Okta, Entra ID, Google, etc.)

Les solutions “payantes” ont un argument difficile à battre : outsourcing du problème, SLA, audits, support. Le coût en est double : argent et dépendance.
L’avantage de VoidAuth en self-hosted est évident : open source et auto-hébergé, avec un contrôle total sur les données, le déploiement et les politiques (à condition que vous soyez l’opérateur).

L’atout différentiel : open source pouvant être hébergé “de vrai”

En pratique, le label open source n’a de sens que s’il permet quelque chose de concret. Avec VoidAuth, cet avantage se traduit par :

• Souveraineté du déploiement : il s’exécute où vous le souhaitez (sur votre serveur, votre datacenter, votre cloud privé).
• Coût prévisible : sans tarifs par utilisateur/MAU croissants avec la taille de votre infrastructure.
• Capacité d’inspection et d’adaptation : vous pouvez revoir, auditer par des tiers si besoin, ou étendre selon votre contexte.
• Éviter le “vendor lock-in” dans votre authentification, enjeu critique de toute architecture.

De plus, dans un contexte où l’intérêt pour les agents locaux, les outils auto-hébergés et la privacy augmente, un SSO propre devient une pièce essentielle du puzzle.

Ce qu’il faut vérifier avant de l’adopter

Pour une adoption responsable (et sans surprises), trois questions importantes méritent réflexion :

1. Maturité et audit : si votre environnement est critique ou réglementé, il vous faut un roadmap clair, des revues de sécurité, et éventuellement des audits externes.
2. Intégration réelle avec vos applications : OIDC et ForwardAuth couvrent beaucoup, mais des exceptions existent.
3. Opération et sauvegardes : en centralisant la connexion, cette composante devient une “infrastructure core”. Haute disponibilité, sauvegardes et restauration ne sont plus optionnels.

FAQs

VoidAuth fonctionne-t-il si mes applications ne supportent pas OIDC ?
Oui, le mode ForwardAuth est justement destiné à protéger les applications sans support natif OIDC en plaçant l’authentification devant le service via le reverse proxy.

Quels avantages offrent les passkeys en environnement auto-hébergé ?
Elles réduisent la dépendance aux mots de passe réutilisés, renforcent la résistance au phishing et simplifient l’accès pour les utilisateurs non techniques (si le flux est bien implémenté).

Quand vaut-il mieux privilégier Keycloak ou Authentik plutôt que VoidAuth ?
Lorsque vous avez besoin d’un IAM complet (SAML, flux avancés, fédération, politiques d’entreprise, intégrations massives) et que vous acceptez une complexité opérationnelle accrue.

Le fait que ce soit open source le rend-il automatiquement plus sécurisé ?
Pas nécessairement. L’open source facilite l’audit et l’inspection, mais la sécurité réelle dépend du design, de la maintenance, des mises à jour, de la configuration, et idéalement d’audits externes.