Outils SSO auto-hébergé et contrôle d'accès

Un auteur XDA a récemment décrit quatre choses qu’il a faites pour sécuriser un serveur Plex avant de l’exposer à Internet : appliquer TLS, arrêter de publier le port 32400 directement via le routeur, placer la chose derrière un proxy inverse et activer l’authentification à deux facteurs pour le compte. Tout ce qui est sensé. Tout ce qui est incomplet. Le proxy inverse met fin à TLS et achemine les noms d’hôte, puis remet la demande à l’application, qui est laissée à décider par elle-même si la personne à l’autre bout devrait y être. Chaque service se termine par sa propre page de connexion, ses propres règles de mot de passe et sa propre idée de ce que signifie « se déconnecter ».

C’est l’écart que comblent les meilleures applications SSO auto-hébergées. Un fournisseur d’identité s’asseoit derrière le proxy inverse, chaque service s’y réfère, l’authentification multifacteur est appliquée une fois pour tout, et révoquer l’accès de quelqu’un est un seul basculement plutôt qu’une visite de douze panneaux d’administration. Nous avons examiné 8 options qui sont activement développées et fonctionnent dans de véritables laboratoires domestiques aujourd’hui, allant des fournisseurs d’identité complets avec leur propre base de données à un seul conteneur qui répond à une seule question oui ou non par demande.

Qu’il faut rechercher dans une application SSO auto-hébergée

Comparaison rapide

Application Meilleur pour Magasin d’utilisateurs propre Protocoles Forward auth Licence
Authentik Un fournisseur d’identité complet avec interface web Oui OIDC, SAML, LDAP, RADIUS Oui, proxy outpost MIT core, paid enterprise tier
Authelia Un portail léger à côté de votre proxy inverse Oui, fichier ou LDAP OIDC provider, forward auth Oui, native Apache 2.0
Tinyauth Obtenir une connexion quelconque devant quelques applications rapidement Oui, plus OAuth et LDAP OIDC, forward auth Oui, native AGPL 3.0
LLDAP Un annuaire partagé que les autres peuvent lire Oui, LDAP uniquement LDAP Non GPL 3.0
oauth2-proxy Ajouter un IdP existant devant une application Non OIDC et OAuth2 client Oui, via nginx auth_request MIT
Zitadel Pistes d’audit et configurations multi-locataires Oui OIDC, SAML, SCIM, LDAP Via OIDC AGPL 3.0
Keycloak La couverture de protocole et de fédération la plus large Oui OIDC, SAML Via oauth2-proxy Apache 2.0
Pomerium Politique décidée par demande, pas par connexion Non OIDC client C’est le proxy Apache 2.0

Pourquoi la couche d’identité est celle que les gens oublient

Les guides de proxy inverse sont partout, et ils se terminent au point où le trafic atteint l’application. Les guides de pare-feu se terminent au port. Aucun ne répond à la question qui importe une fois qu’un nom d’hôte est public : qui est autorisé, prouvé comment et révoqué quand.

Le résultat est un laboratoire domestique où le proxy inverse est bien configuré et les applications derrière sont chacune protégées par ce que leur développeur a expédié. Certains ont TOTP. Certains ont un seul mot de passe administrateur partagé dans une variable d’environnement. Certains ont un assistant de configuration qui reste ouvert jusqu’à ce que quelqu’un le visite. Un fournisseur d’identité devant tous les transforme en une seule porte, et la porte est la seule chose que vous devez bien faire.

Les applications

1. Authentik : meilleur au global pour SSO auto-hébergé

Authentik est celui sur lequel finissent la plupart des laboratoires domestiques, et pour une bonne raison : il couvre les deux côtés du problème. Les applications qui parlent OIDC ou SAML obtiennent un fournisseur d’identité approprié avec un point de terminaison de découverte, des réclamations de groupe et des écrans de consentement. Les applications qui ne parlent rien obtiennent un proxy outpost, que votre proxy inverse appelle en tant que forward auth et qui transmet le nom d’utilisateur et l’e-mail authentifiés en tant qu’en-têtes. Tout est configuré via une interface web, y compris le générateur de flux, qui vous permet de décider exactement quand l’authentification multifacteur est demandée et quand une session peut être réutilisée. L’inscription, la récupération et la réinitialisation du mot de passe sont en libre-service, ce qui a de l’importance quand quelqu’un d’autre que vous a besoin d’un compte.

Où il s’en sort : c’est le plus lourd des options légères. Le déploiement par défaut est un conteneur serveur, un conteneur de travail, Postgres et Redis, et le projet demande environ 2 cœurs de processeur et 2 Go de RAM avant d’ajouter quoi que ce soit. Le système de flux est puissant et en conséquence facile à mal configurer, et un flux d’authentification rompu vous verrouille de l’interface d’administration aussi efficacement qu’il verrouille tout le monde d’autre.

Coût : le noyau est sous licence MIT et gratuit sans limites d’utilisateurs. Un niveau d’entreprise payant ajoute un support et des fonctionnalités destinées aux entreprises plutôt qu’aux foyers.

Plates-formes : Docker ou Kubernetes sur Linux, et Docker Desktop sur Windows et macOS.

Télécharger : goauthentik.io · GitHub

Conclusion : exécutez Authentik pour SSO auto-hébergé si vous voulez un système qui gère à la fois les applications modernes et celles qui n’implémenteront jamais OIDC, et vous avez de la RAM à perdre.

2. Authelia : meilleure option légère avec configuration que vous pouvez contrôler les versions

Authelia est un seul binaire Go qui s’asseoit à côté de votre proxy inverse et répond une question par demande. Les utilisateurs vivent dans un fichier YAML ou un annuaire LDAP qu’Authelia ne possède pas, les règles d’accès vivent dans le même YAML, et toute la configuration est un artefact que vous pouvez valider dans un référentiel privé et restaurer en une minute. Il prend en charge TOTP, les clés de sécurité WebAuthn, Duo push et les clés de passe, et il est certifié OpenID en tant que fournisseur OIDC, donc les applications qui parlent OIDC peuvent lui parler directement plutôt que via des en-têtes. Les intégrations de forward auth sont documentées pour nginx, Traefik, Caddy, HAProxy et Envoy.

Où il s’en sort : il n’y a pas d’interface d’administration. Ajouter un utilisateur signifie éditer un fichier et recharger, ce qui convient à un foyer et est douloureux pour quoi que ce soit de plus grand. La réinitialisation du mot de passe nécessite une configuration de courrier fonctionnelle. La syntaxe d’enregistrement du client OIDC est inflexible, et une faute de frappe dans un URI de redirection produit un message d’erreur qui ne vous dit pas quel bout a tort.

Coût : gratuit et sous licence Apache 2.0.

Plates-formes : Docker ou un binaire statique sur Linux, plus Docker sur Windows et macOS.

Télécharger : authelia.com · GitHub

Conclusion : le bon choix si vos règles d’accès sont stables, vous êtes à l’aise dans YAML et vous préférez sauvegarder un fichier plutôt qu’une base de données.

3. Tinyauth : meilleur pour obtenir une connexion devant les choses ce soir

Tinyauth est ce que vous utilisez quand Authelia se sent comme trop de cérémonie. Un conteneur, une config et une page de connexion devant ce que votre proxy inverse lui envoie. Il gère les utilisateurs locaux, LDAP et les connexions OAuth auprès de fournisseurs comme GitHub et Google, prend en charge TOTP et applique des règles d’accès par application. La version 5.1.0 a obtenu la certification OpenID pour le profil Basic OP à la mi-2026, il n’est donc plus seulement un shim forward-auth : les applications qui parlent OIDC peuvent l’utiliser comme fournisseur. Les intégrations documentées couvrent Traefik, nginx et Caddy.

Où il s’en sort : c’est jeune, et le projet lui-même avertit que les changements de configuration se produisent souvent entre les versions, donc les mises à jour ont besoin de lire les notes de version plutôt que de tirer aveuglément une nouvelle balise. Il n’y a pas de SAML, pas de RADIUS et pas d’inscription libre-service pour les personnes qui ne sont pas déjà dans l’annuaire. Si votre laboratoire domestique grandit au-delà d’une poignée de services avec des groupes distincts, vous le dépasserez.

Coût : gratuit et sous licence AGPL 3.0.

Plates-formes : Docker sur Linux, Windows et macOS.

Télécharger : tinyauth.app · GitHub

Conclusion : la réponse honnête la plus rapide à « il n’y a pas de connexion devant cela du tout », et assez petite pour coûter presque rien à côté de quelque chose de plus grand plus tard.

4. LLDAP : meilleur pour un annuaire d’utilisateurs que d’autres peuvent lire

LLDAP n’est pas un portail SSO. C’est un petit serveur Rust qui parle assez LDAP pour que d’autres logiciels s’authentifient contre lui, avec une interface web pour gérer les utilisateurs et les groupes et une option pour que les utilisateurs réinitialisent leur propre mot de passe par e-mail. Cette portée étroite est le but : Authelia, Authentik, Keycloak, Nextcloud, Jellyfin et une longue liste d’applications auto-hébergées peuvent tous lire depuis lui, vous obtenez donc un endroit où les comptes sont créés et un endroit où ils sont désactivés. Il stocke les données dans SQLite par défaut, avec MySQL, MariaDB et PostgreSQL comme alternatives, et expose une API GraphQL si vous gérez les utilisateurs à partir du code.

Où il s’en sort : ce n’est délibérément pas un serveur LDAP complet. Les navigateurs LDAP génériques échouent souvent contre lui, son schéma de hachage de mot de passe signifie qu’il ne peut pas distribuer des hachés pour qu’un autre service valide, et le projet nomme Synology comme incompatible. Il ne fait aucune autorisation par lui-même, donc quelque chose d’autre doit toujours appliquer les règles d’accès.

Coût : gratuit et sous licence GPL 3.0.

Plates-formes : Docker ou un binaire sur Linux, et Docker sur Windows et macOS.

Télécharger : GitHub

Conclusion : appairez-le avec Authelia ou Tinyauth quand vous voulez un annuaire partagé sans déployer un vrai déploiement LDAP, et sautez-le entièrement si votre fournisseur d’identité possède déjà vos utilisateurs.

5. oauth2-proxy : meilleur pour mettre un IdP que vous exécutez déjà devant une application

oauth2-proxy ne possède pas de comptes. C’est un client qui envoie les visiteurs à un fournisseur OIDC ou OAuth2 que vous possédez déjà, vérifie le résultat, puis fait un proxy de la demande à votre application ou répond à la auth_request nginx par un oui ou un non. Il prend en charge OIDC générique aux côtés d’intégrations dédiées pour Google, Microsoft Entra ID, GitHub et d’autres, et les implémentations spécifiques au fournisseur peuvent extraire l’adhésion à un groupe et la transmettre en tant qu’en-têtes. C’est un projet CNCF Sandbox et il fait tranquillement ce travail depuis des années.

Où il s’en sort : il résout exactement un problème et s’attend à ce que vous ayez résolu les autres. Il n’y a pas de gestion des utilisateurs, pas d’authentification multifacteur propre et pas de moteur de politique au-delà des listes de permission d’e-mails, de domaines et de groupes. Obtenir des réclamations de groupe via une application signifie faire correspondre les noms de réclamations de votre fournisseur manuellement, et le mode de défaillance est une connexion réussie sans permissions.

Coût : gratuit et sous licence MIT.

Plates-formes : Docker ou un binaire sur Linux, macOS et Windows.

Télécharger : oauth2-proxy docs · GitHub

Conclusion : le bon choix quand vous exécutez déjà Authentik, Keycloak ou Zitadel et avez besoin qu’une application têtue la respecte.

6. Zitadel : meilleur quand vous voulez une piste d’audit de chaque événement d’identité

Zitadel est une plateforme d’identité Go construite sur l’approvisionnement en événements, ce qui signifie que chaque changement à un utilisateur, un rôle ou une session est stocké en tant qu’événement immuable plutôt qu’une ligne mise à jour. Pour un laboratoire domestique cela semble être de la sur-ingénierie jusqu’à la première fois que vous avez besoin de répondre quand un compte a été créé et par qui. Il couvre OIDC, SAML 2.0, OAuth 2.0, SCIM 2.0 et LDAP, prend en charge OTP par application, e-mail et SMS, plus U2F et les clés de passe FIDO2, et est multi-locataire dès le départ si vous hébergez des services pour plus d’un foyer ou un entreprise secondaire.

Où il s’en sort : il nécessite PostgreSQL 14 ou version ultérieure, et la configuration suppose que vous comprenez le modèle d’organisation et de projet avant de créer votre première application. La conception API-first est excellente si vous programmez votre infrastructure et plus lourde que nécessaire si vous voulez juste une page de connexion. L’auto-hébergement est AGPL 3.0, ce qui vaut la peine de lire si vous prévoyez de construire quelque chose de commercial dessus.

Coût : gratuit pour l’auto-hébergement. Le service hébergé est facturé séparément.

Plates-formes : Docker ou Kubernetes sur Linux, plus des binaires pour Linux et macOS.

Télécharger : zitadel.com · GitHub

Conclusion : choisissez Zitadel plutôt que Authentik quand la journalisation de conformité ou la multi-location est une véritable exigence plutôt qu’une bonne idée.

7. Keycloak : meilleur pour la couverture de protocole et de fédération la plus large

Keycloak est l’option d’entreprise, maintenant un projet CNCF avec plus d’une décennie d’utilisation en production derrière lui. Si un logiciel supporte le SSO du tout, il documente presque certainement une intégration Keycloak. Il se fédère contre LDAP et Active Directory existants, courtiers aux fournisseurs externes, fait une autorisation fine avec son propre moteur de politique et gère les coins SAML maladroits que les outils plus légers ignorent. Commencer est vraiment rapide avec start-dev dans Docker, qui fonctionne contre une base de données intégrée pour l’évaluation.

Où il s’en sort : start-dev n’est pas une configuration de production, et passer à l’une signifie une base de données externe, une configuration de nom d’hôte qui fait trébucher presque tout le monde la première fois, et un runtime Java dont l’utilisation de la mémoire commence où Authelia se termine. Il n’a pas son propre mode forward-auth, donc les applications qui ne parlent pas OIDC ou SAML ont besoin de oauth2-proxy devant eux. La console d’administration suppose un vocabulaire (realms, clients, mappers) qu’aucun guide de laboratoire domestique n’aurait pu vous enseigner.

Coût : gratuit et sous licence Apache 2.0.

Plates-formes : Docker ou une distribution Java sur Linux, Windows et macOS.

Télécharger : keycloak.org · GitHub

Conclusion : cela vaut le coût de configuration si vous avez besoin de la fédération SAML ou si vous vous entraînez pour la même pile au travail, et c’est difficile à justifier pour six conteneurs derrière Traefik.

8. Pomerium : meilleur pour la politique décidée par demande, pas par connexion

Pomerium inverse l’arrangement habituel. Au lieu d’un fournisseur d’identité qui accorde une session et un proxy qui lui fait confiance, Pomerium est le proxy, et il évalue une politique à chaque demande unique en utilisant l’identité d’un fournisseur OIDC en amont plus le contexte de la demande elle-même. Les politiques sont écrites en tant que configuration plutôt que cliquées ensemble, donc les règles d’accès vivent dans le même référentiel que le reste de votre infrastructure. C’est sans client, ce qui signifie que personne n’a à installer une application VPN pour atteindre un service interne, et c’est sous licence Apache 2.0 avec un plan de contrôle géré vendu séparément pour les organisations qui veulent une GUI.

Où il s’en sort : il ne possède pas d’utilisateurs, donc vous avez toujours besoin d’Authentik, Keycloak, Zitadel ou d’un fournisseur hébergé derrière. Le déploiement typique est plus d’un conteneur avec un stockage persistant. Et comme il remplace votre proxy inverse plutôt que de s’asseoir à côté, adopter Pomerium signifie refaire le routage et les certificats qui fonctionnent déjà, ce qui est beaucoup d’interférence pour un laboratoire domestique qui veut juste une page de connexion.

Coût : gratuit et open source pour l’auto-hébergement. Le plan de contrôle hébergé est un produit payant.

Plates-formes : Docker ou Kubernetes sur Linux, plus des binaires pour Linux et macOS.

Télécharger : pomerium.com · GitHub

Conclusion : choisissez quand les décisions d’accès ont besoin de tenir compte de plus que « cette personne s’est connectée il y a une heure », et sur-ingénier pour quoi que ce soit de plus petit.

La friction que personne ne mentionne dans les guides d’installation

La moitié de vos applications ne parlent pas OIDC. Forward auth est la solution de secours : le proxy inverse demande au fournisseur d’identité, et en cas de succès transmet les en-têtes comme Remote-User et Remote-Email à l’application. Cela ne fonctionne que si l’application peut être configurée pour faire confiance à ces en-têtes, et c’est seulement sûr si l’application n’est pas accessible sauf via le proxy. Liez le conteneur à un réseau Docker interne plutôt qu’à un port d’hôte, car une application qui fait confiance aux en-têtes d’identité leur fera confiance de quiconque peut la joindre directement.

Quand le fournisseur d’identité est arrêté, tout est arrêté. Postgres remplit un disque, une mise à jour de conteneur échoue, un certificat expire, et soudain rien dans la maison se connecte. Décidez du chemin du verre brisé avant d’en avoir besoin : gardez au moins une route vers votre infrastructure qui ne traverse pas le fournisseur d’identité, comme SSH sur un VPN maillé ou l’accès à la console sur le réseau local, et sachez quel service vous exclure temporairement du forward auth pour restaurer le reste. Écrivez-le quelque part qui n’est pas derrière la connexion que vous venez de perdre.

Les sauvegardes doivent couvrir le magasin d’identité, pas seulement la configuration. Pour Authelia, l’état est un fichier YAML plus une petite base de données d’inscriptions TOTP et WebAuthn. Pour Authentik, Zitadel ou Keycloak, c’est une base de données Postgres plus une clé secrète, et restaurer la base de données sans la clé secrète correspondante vous donne un service qui démarre puis refuse chaque session. Videz la base de données selon un horaire, stockez la clé secrète séparément et testez une restauration une fois plutôt que de découvrir l’écart lors d’une panne.

SSO devant un serveur de médias casse les applications natives. C’est le piège spécifique dans le scénario Plex. Une application de télévision ou un client mobile ne peut pas terminer un flux de connexion basé sur un navigateur, donc placer forward auth sur tout le nom d’hôte arrête ces clients de se connecter du tout. La solution habituelle est d’exclure les chemins d’API du SSO, ce qui vous ramène tranquillement à l’authentification du serveur de médias pour exactement le trafic qui porte votre bibliothèque. La réponse plus propre est de garder le trafic des clients natifs sur un VPN maillé et d’appliquer SSO à l’interface web uniquement, ou d’utiliser un fournisseur d’identité que le serveur de médias soutient directement plutôt que de l’envelopper de l’extérieur.

Ne jamais faire du fournisseur d’identité le maillon faible. Son interface d’administration ne doit être accessible que depuis votre réseau interne ou via VPN, l’authentification multifacteur doit être obligatoire pour chaque compte pouvant modifier la politique, et la vérification des certificats reste partout. Un fournisseur d’identité mal configuré est pire que rien, car il concentre l’accès au lieu de le distribuer.

Comment choisir le bon

Pour la plupart des gens qui ouvrent un serveur domestique à Internet pour la première fois, la réponse honnête est Authentik si le matériel peut le supporter, et Authelia s’il ne peut pas. Les deux vous donnent une connexion, l’authentification multifacteur appliquée et un endroit pour révoquer l’accès, ce qui est tout le point.

FAQ

Quelle est la meilleure solution SSO auto-hébergée pour un laboratoire domestique ?

Authentik couvre la gamme la plus large de situations, car il fonctionne en tant que fournisseur d’identité complet pour les applications qui parlent OIDC ou SAML et en tant que passerelle forward-auth pour les applications qui ne parlent ni l’une ni l’autre. Authelia convient mieux sur du matériel limité ou quand vous voulez toute la configuration dans un fichier contrôlé par la version. Les deux sont gratuits et les deux appliquent l’authentification multifacteur sur chaque service derrière eux.

Ai-je besoin de SSO si mon proxy inverse a déjà TLS et un mot de passe ?

Ils résolvent des problèmes différents. TLS protège le trafic en transit et basic auth protège un seul nom d’hôte avec un secret partagé qui ne peut pas être révoqué par personne ou soutenu par l’authentification multifacteur. SSO donne à chaque personne sa propre identité, applique un deuxième facteur une fois pour tout et vous permet de révoquer l’accès en un seul endroit. Un proxy inverse est l’endroit où SSO est appliqué, pas un substitut à celui-ci.

Puis-je mettre SSO devant Plex ou Jellyfin ?

Partiellement. L’interface web fonctionne bien derrière forward auth. Les applications natives sur les téléphones, les téléviseurs et les boîtes de streaming ne peuvent pas terminer une connexion basée sur un navigateur, elles se cassent donc à moins que vous n’excluiez les chemins d’API, ce qui affaiblit la protection du trafic qui compte le plus. Gardez les clients natifs sur un VPN maillé et protégez l’interface web avec SSO, ou utilisez un fournisseur d’identité que le serveur de médias intègre directement.

Que se passe-t-il si mon fournisseur d’identité est hors ligne ?

Chaque service derrière arrête d’accepter les connexions, et les sessions existantes expirent selon leur calendrier normal. Planifiez-le : gardez l’accès au réseau local ou VPN à votre hôte qui ne dépend pas du fournisseur d’identité, gardez un moyen documenté de désactiver forward auth sur un service, et stockez les codes de récupération et les sauvegardes de base de données quelque part accessible sans se connecter.

Keycloak est-il excessif pour un serveur domestique ?

Généralement, oui. Les forces de Keycloak sont la fédération SAML, le courtage aux fournisseurs externes et l’autorisation fine à l’échelle organisationnelle, et son coût est un runtime Java, une base de données externe et un vocabulaire que vous devez d’abord apprendre. Pour une douzaine de conteneurs derrière un proxy inverse, Authentik ou Authelia fournissent le même résultat pratique avec beaucoup moins de configuration.

Ces outils stockent-ils mes mots de passe et comment les sauvegarder ?

Authentik, Authelia, Zitadel, Keycloak, LLDAP et Tinyauth stockent tous les identifiants sous une forme quelconque. oauth2-proxy et Pomerium ne stockent rien et délèguent en amont. Pour ceux qui le font, sauvegardez la base de données ou le fichier de configuration avec la clé secrète de l’instance, car une restauration sans la clé secrète correspondante invalide chaque session et deuxième facteur inscrit.