Pourquoi le SSO est souvent payant en auto-hébergé

Le coût du SSO

Dans les logiciels auto-hébergés, le coût du SSO désigne le modèle dans lequel l’application est gratuite, mais où l’authentification unique (SSO) est la seule fonctionnalité payante. Vous pouvez exécuter l’ensemble sur votre propre VPS, sans clé de licence ni limite de comptes. Puis vous ouvrez la page de documentation consacrée à l’authentification et vous découvrez qu’OpenID Connect (OIDC) ou SAML (Security Assertion Markup Language) est réservé à une offre payante.

Ce point est plus important qu’une fonctionnalité ordinaire réservée aux offres payantes, car le SSO permet à plusieurs services auto-hébergés de fonctionner comme un seul système. Un fournisseur d’identité (IdP) vous permet d’avoir un compte par personne, une seule politique de mots de passe, un seul endroit où activer l’authentification multifacteur (MFA) et un seul endroit où désactiver un compte. Sans cela, chaque application conserve sa propre petite base d’utilisateurs, que vous devez gérer manuellement.

Ce modèle est suffisamment ancien pour faire l’objet d’un classement public. Le SSO Wall of Shame, disponible sur sso.tax, recense les fournisseurs qui facturent un supplément important pour l’authentification unique. Les entrées remontent à 2018 et son auteur fixe un seuil raisonnable : « Si votre prise en charge du SSO entraîne une hausse de prix de 10 %, vous ne figurez pas dans cette liste. » La plupart des logiciels concernés sont propriétaires. La même logique tarifaire apparaît désormais dans des projets open source que vous hébergez vous-même.

Pourquoi les mainteneurs réservent l’authentification unique à une offre payante

Il y a deux raisons, et elles sont toutes les deux légitimes. Le SSO coûte cher à prendre en charge, et c’est l’une des rares fonctionnalités pour lesquelles une grande organisation accepte de payer.

Le coût de support est réel, car une intégration avec un fournisseur d’identité n’est jamais vraiment terminée. Chaque IdP formate ses claims d’une manière légèrement différente. Le mapping des groupes, la durée de vie des sessions, les URL de redirection et le décalage d’horloge peuvent chacun provoquer des bugs de connexion. Un bug de connexion bloque tous les utilisateurs en même temps, ces tickets deviennent donc urgents. Viennent ensuite les demandes associées : groupes imbriqués, mapping des rôles, provisioning automatique avec SCIM (system for cross-domain identity management) et journaux d’audit consultés par une équipe chargée de la conformité.

La question des revenus relève de l’arithmétique, pas de la malveillance. Une entreprise qui ne peut pas connecter l’application à son propre IdP ne la déploiera pas du tout. Le SSO établit donc une séparation claire entre l’utilisateur qui paie et celui qui ne paie pas. Un projet open core doit placer cette séparation quelque part. Le SSO s’y prête mieux que presque toute autre fonctionnalité, ce qui explique pourquoi tant de projets le choisissent.

Une correction s’impose toutefois face à la plainte habituelle : consultez le changelog avant de supposer qu’une fonctionnalité a été supprimée, car une suppression apparaît dans les release notes. Pour les projets que j’ai vérifiés dans le cadre de cet article, les fonctionnalités SSO payantes avaient été conçues pour l’offre payante dès le départ. Je n’ai trouvé aucun cas où un SSO gratuit fonctionnel aurait été retiré. Grafana est un exemple typique. Sa page SAML contient une note d’une ligne : « Available in Grafana Enterprise and Grafana Cloud », tandis que OAuth générique avec votre propre issuer fonctionne dans la version open source.

Le coût réel de la gestion du SSO

La facture n’est que la moitié la moins importante. Les offres payantes sont facturées par utilisateur. Le coût augmente donc avec la taille de l’équipe, tandis que l’hébergement et les mises à niveau restent à votre charge.

Le coût principal vient du travail manuel lié aux identités. Il se répartit en quatre points.

• Un gestionnaire de mots de passe par application. Un mot de passe réutilisé devient donc une faille dans chaque application qui l’utilise.
• La révocation des accès lors du départ d’un collaborateur, faite de mémoire. Vous devez vous rappeler tous les services auxquels cette personne a eu accès. Celui que vous oubliez est précisément celui qui posera problème.
• Le MFA configuré application par application, lorsque l’application le prend en charge.
• Les comptes partagés, qui deviennent la réalité dans les petites équipes soumises à cette contrainte.

Ce dernier point mérite une explication distincte. Lorsqu’une équipe partage un même compte administrateur dans un gestionnaire de documents, la piste d’audit enregistre le même nom pour toutes les actions. Vous ne pouvez donc pas savoir qui a supprimé la facture. Les permissions par utilisateur ne fonctionnent plus non plus, puisqu’il n’y a qu’un seul utilisateur. C’est le véritable coût de la gestion du SSO : elle pousse les petites équipes vers un compte partagé unique, ce qui est pire que toutes les autres solutions.

La checklist à exécuter avant d’adopter quoi que ce soit

Exécutez-la avant docker compose up, et non après que l’application contient 400 documents.

1. Ouvrez la page d’authentification de la documentation et lisez la note sur les niveaux située en haut. Les fonctionnalités payantes sont signalées par un badge ou une phrase indiquant leur disponibilité.
2. Vérifiez que l’application prend en charge OIDC ou SAML avec votre propre issuer, et non uniquement avec une liste fixe de fournisseurs publics.
3. Vérifiez le mapping des rôles et des groupes. Créer l’utilisateur ne représente que la moitié du travail. Attribuer manuellement les permissions dans dix applications est la moitié la plus pénible.
4. Vérifiez si l’application accepte, dans un header transmis par un proxy de confiance, un nom d’utilisateur déjà authentifié. Vérifiez également si vous pouvez définir précisément le proxy auquel elle fait confiance.
5. Consultez l’historique de la licence dans git et vérifiez si les contributeurs signent un CLA (contributor licence agreement).
6. Vérifiez la procédure d’offboarding. Déterminez ce qui arrive aux tokens API (application programming interface) et aux sessions actives lorsque le compte IdP est désactivé.

C’est au point 2 que surviennent la plupart des déceptions. Un bouton « Sign in with Google » ne correspond pas à OIDC avec votre identity provider : il s’agit d’une intégration fixe avec un seul fournisseur. Une véritable prise en charge vous demande une URL d’issuer, puis récupère tout le reste via la discovery. Vous pouvez vérifier le fonctionnement de votre fournisseur avec une seule commande.

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

Trois URL sont renvoyées par un provider opérationnel. Un résultat vide ou une réponse 404 indique généralement que le chemin de discovery est incorrect. Ce chemin dépend du fournisseur : Keycloak le publie sous /realms/<realm>/.well-known/openid-configuration. Si l’application ne comporte aucun champ pour une URL d’issuer, elle ne peut pas communiquer avec votre IdP, quelle que soit la liste des fonctionnalités annoncées.

Le point 6 prend souvent les équipes au dépourvu plusieurs semaines après le départ d’une personne. Désactiver le compte dans l’IdP empêche les nouvelles connexions. Cela ne révoque pas un token API émis auparavant par l’application, car celle-ci valide elle-même ce token et ne consulte jamais l’IdP à son sujet. L’offboarding comporte donc deux étapes : désactiver le compte dans l’IdP, puis supprimer l’utilisateur ou ses tokens dans chaque application.

Ce que disent réellement les badges de niveau

Ces informations ont été vérifiées dans la documentation de chaque projet en août 2026. Commençons par les offres payantes.

Grafana présente SAML comme « Available in Grafana Enterprise and Grafana Cloud », avec la synchronisation des équipes et le provisionnement SCIM. OAuth générique, GitHub OAuth, LDAP (lightweight directory access protocol) et l’auth proxy sont tous disponibles dans l’édition open source. Un petit auto-hébergeur peut donc toujours se connecter via son propre fournisseur. L’offre payante commence avec SAML, et non avec le single sign-on dans son ensemble. C’est la nuance que l’expression « taxe SSO » tend à gommer.

Metabase est plus explicite. Sa documentation indique : « SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud). » L’édition open source conserve l’authentification par mot de passe et LDAP.

Passbolt classe sa documentation SSO dans les offres Pro et Cloud. L’édition Community ne dispose donc pas de cette fonctionnalité. Les fournisseurs documentés incluent Keycloak et Entra ID.

Passons maintenant à l’autre cas, car ce modèle est loin d’être universel.

• GitLab Self-Managed affiche « Tier: Free, Premium, Ultimate » sur sa page SAML. SAML avec votre propre instance GitLab ne coûte donc rien.
• Paperless-ngx configure OIDC via django-allauth avec PAPERLESS_SOCIALACCOUNT_PROVIDERS, masque le formulaire de connexion local avec PAPERLESS_DISABLE_REGULAR_LOGIN et associe les claims aux groupes avec PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• Planka accepte OIDC_ISSUER, OIDC_CLIENT_ID et OIDC_CLIENT_SECRET, utilise openid profile email comme scopes par défaut et attribue le rôle d’administrateur à partir d’un claim de rôle avec OIDC_ADMIN_ROLES.
• BookStack active OIDC avec AUTH_METHOD=oidc, puis associe les groupes du fournisseur à ses propres rôles avec OIDC_USER_TO_GROUPS=true et OIDC_GROUPS_CLAIM.
• Vaultwarden a ajouté la « prise en charge du SSO avec OpenID Connect » dans la version 1.35.0, le 27 décembre 2025, à partir d’une pull request d’un contributeur qui maintenait cette fonctionnalité dans un fork.
• listmonk prend en charge la connexion OIDC en plus de ses rôles utilisateur depuis la version 4.0.0.

Tenez-en compte au moment de choisir, et non après vous être engagé sur une solution. Un tableau kanban Planka et les autres alternatives auto-hébergées à Trello ne traitent pas tous l’identité de la même manière. Il en va de même pour BookStack, Wiki.js et Outline. La disponibilité gratuite d’OIDC est un critère à évaluer au même titre que les limites de stockage ou les clients mobiles. Si vous êtes encore en train d’établir votre liste, ce qu’il faut auto-héberger en 2026 constitue un point de départ raisonnable. Le gestionnaire de documents Paperless-ngx et Vaultwarden proposent tous deux OIDC gratuitement aujourd’hui.

Pourquoi un reverse proxy devant l’application ne constitue pas un SSO

La solution courante consiste à utiliser une authentification déléguée. Le reverse proxy met chaque requête en attente, demande à un service d’authentification si ce navigateur est connecté, puis transmet la requête à l’application uniquement si c’est le cas. authentik appelle cela un proxy provider, avec un mode forward auth pour une application unique et un autre pour un domaine entier. Authelia et oauth2-proxy assurent la même fonction.

Un bloc de site Caddy peut se présenter ainsi, conformément à l’exemple fourni par authentik.

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

La capitalisation de ces noms d’en-tête est importante dans Caddy, car un nom incorrect arrive vide. Pour chaque requête qu’il autorise, l’outpost définit X-authentik-username, X-authentik-email, X-authentik-groups et quelques autres.

Voici ce que cela permet. Personne n’atteint l’application sans passer d’abord par votre fournisseur d’identité. Un formulaire de connexion non corrigé n’est donc plus exposé à Internet, et la MFA s’applique immédiatement à tout ce qui se trouve derrière le proxy.

Voici ce que cela ne permet pas : gérer l’identité dans l’application. L’application conserve ses propres comptes et sa propre notion de l’utilisateur connecté. Si tout le monde passe le proxy et arrive sur un compte administrateur partagé, vous avez une porte d’entrée bien protégée, mais une session anonyme unique derrière celle-ci. Le journal d’audit affiche toujours un seul nom. Les permissions ne peuvent toujours pas différer d’une personne à l’autre. Appeler cette configuration du SSO est une erreur de sécurité, car le processus de retrait d’un utilisateur n’est que partiellement couvert : supprimer la personne de votre IdP ferme la porte d’entrée, mais un jeton d’API qu’elle a créé dans l’application continue de fonctionner pour toute personne pouvant atteindre directement l’application.

Sécuriser l’authentification par en-tête

Certaines applications acceptent un nom d’utilisateur fourni par le proxy. Vous obtenez ainsi une identité par utilisateur sans SSO payant. Le paramètre porte un nom différent selon les projets.

Grafana appelle cette fonctionnalité auth proxy et la désactive par défaut. Le nom d’en-tête par défaut est X-WEBAUTH-USER. Vous pouvez le remplacer par celui que votre proxy définit.

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

whitelist est la ligne souvent ignorée. La documentation de Grafana précise qu’elle empêche les utilisateurs d’usurper l’en-tête. Elle doit donc contenir l’adresse de votre proxy, et rien d’autre. Gitea propose la même fonctionnalité sous d’autres noms et fournit une valeur par défaut plus sûre.

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

REVERSE_PROXY_TRUSTED_PROXIES vaut par défaut 127.0.0.0/8,::1/128. REVERSE_PROXY_LIMIT indique combien de proxies Gitea fait confiance dans la chaîne. Si vous définissez cette limite à zéro, la gestion de l’en-tête est entièrement désactivée.

Paperless-ngx propose PAPERLESS_ENABLE_HTTP_REMOTE_USER avec PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME. Sa documentation contient l’avertissement applicable à tous ces paramètres :

Cela permet de s’authentifier en ajoutant simplement un en-tête Remote-User: <username> à une requête. À utiliser avec prudence !

Deux règles permettent de sécuriser l’authentification par en-tête. Elles concernent toutes deux l’accessibilité. Premièrement, l’application doit être inaccessible autrement que par le proxy. Toute personne pouvant ouvrir une socket vers l’application peut envoyer cet en-tête et se faire passer pour n’importe quel utilisateur. Avec Docker, ports: ["8000:8000"] publie le port sur toutes les interfaces. Liez-le donc à l’adresse loopback avec ports: ["127.0.0.1:8000:8000"], ou supprimez le port publié et placez le proxy sur le même réseau Docker. Deuxièmement, le proxy doit supprimer toute copie de l’en-tête reçue du client. Ainsi, la seule valeur visible par l’application est celle que votre proxy définit après l’authentification.

Vérifiez ces deux points. Exécutez la première commande depuis une machine située en dehors de votre VPS, puis la deuxième directement sur le serveur.

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

La commande curl doit échouer lors de la connexion, et ss doit afficher 127.0.0.1:8000 plutôt que 0.0.0.0:8000. Une première ligne contenant HTTP/1.1 302 Found signifie que l’application répond directement sur Internet. N’importe qui peut donc se connecter en indiquant n’importe quel utilisateur dans un en-tête.

Choisissez une solution lorsqu’aucun SSO gratuit n’existe

Voici les quatre options, dans l’ordre où je les essaierais.

1. Choisissez l’application qui intègre OIDC. Lorsque deux projets remplissent la même fonction et que l’un communique gratuitement avec votre identity provider, cela représente une réelle différence de coût d’exploitation.
2. Utilisez honnêtement forward auth. Pour un outil d’administration doté d’un seul compte et utilisé par une seule personne, un proxy en amont suffit. L’identité de chaque utilisateur dans l’application n’apporte rien dans ce cas.
3. Payez. Si l’application est essentielle à votre travail et que le prix par utilisateur correspond à la taille de votre équipe, cet argent contribue à maintenir le projet. L’alternative consiste à payer avec vos soirées.
4. Posez la question au projet upstream, après avoir recherché dans l’issue tracker. Le support OIDC de Vaultwarden est arrivé par le fork d’un contributeur et une pull request restée ouverte longtemps. Une demande de fonctionnalité accompagnée d’une implémentation fonctionnelle peut donc parfois être intégrée à l’édition gratuite.

Rien de tout cela ne fonctionne sans votre propre identity provider. C’est le premier composant à mettre en place. Exécuter authentik sur un VPS vous fournit un provider OIDC et SAML, ainsi que l’outpost forward auth utilisé plus haut. La comparaison de Keycloak, authentik et Zitadel présente les compromis si vous préférez ne pas encore vous engager.

Historique des licences et raison de sa présence dans la checklist

Le dernier élément de la checklist concerne l’avenir, car la répartition actuelle des licences n’est qu’un instantané. Deux cas bien documentés montrent à quelle vitesse la situation peut évoluer, dans les deux sens. HashiCorp a adopté la Business Source License 1.1 pour toutes ses futures releases le 10 August 2023, tandis que les releases précédentes sont restées sous MPL 2.0 (Mozilla Public License). Redis est passé à la SSPL (server side public license) en March 2024, puis a annoncé le 1 May 2025 que Redis 8 serait également distribué sous AGPLv3 (GNU Affero General Public License).

Interprétez ces deux cas comme des indications sur le mécanisme, et non sur les motivations. La licence que vous consultez aujourd’hui s’applique à la version que vous installez aujourd’hui. Un projet qui détient l’ensemble de ses droits d’auteur peut modifier seul les conditions de sa prochaine release. C’est pourquoi la question relative au CLA figure dans la checklist : une cession étendue des droits d’auteur permet une relicence unilatérale.

Vérifiez vous-même l’historique d’un projet avant de vous appuyer dessus.

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

Une courte liste de commits, principalement issus de l’import initial, est un bon signe. Plusieurs réécritures du fichier de licence signifient que vous devez lire le message de chaque commit avant de vous baser sur les conditions actuelles.

FAQ

Quelle est la taxe SSO ?

La taxe SSO consiste à facturer le single sign-on comme fonctionnalité premium, alors que le reste du produit est gratuit ou peu coûteux. Dans les logiciels auto-hébergés, cela prend la forme d’une application open source que vous pouvez exécuter sans clé de licence, mais dont la connexion OIDC ou SAML est réservée à une offre payante. Le nom vient du SSO Wall of Shame de sso.tax, qui recense les éditeurs facturant cette fonctionnalité à un prix très élevé. Pour l’auto-hébergeur, la conséquence est que chaque application conserve sa propre base d’utilisateurs. Les comptes doivent donc être créés et supprimés manuellement.

Une reverse proxy avec forward auth est-elle équivalente au SSO ?

Non. Le forward auth protège le point d’entrée : votre proxy interroge le fournisseur d’identité avant de transmettre la moindre requête à l’application. L’application située derrière le proxy utilise toujours ses propres comptes. Si tout le monde arrive sur une même connexion partagée, vous obtenez donc une session anonyme unique et un journal d’audit ne contenant qu’un seul nom. L’identité propre à chaque utilisateur n’est réellement transmise que lorsque l’application lit le nom d’utilisateur dans un en-tête. C’est notamment possible avec le proxy d’authentification de Grafana, l’authentification reverse proxy de Gitea et PAPERLESS_ENABLE_HTTP_REMOTE_USER de Paperless-ngx. Ces paramètres ne sont sûrs que si l’application n’est accessible qu’au travers du proxy. L’en-tête est en effet une simple chaîne de caractères que n’importe quel client peut envoyer.

Quelles applications auto-hébergées incluent OIDC dans l’édition gratuite ?

Vérification effectuée à partir de la documentation des projets en août 2026 : Paperless-ngx, Planka, BookStack, Gitea, listmonk et Vaultwarden prennent tous en charge OIDC dans leurs versions gratuites. GitLab Self-Managed indique également SAML dans la catégorie Tier: Free. La version open source de Grafana prend en charge OAuth générique avec votre propre issuer, tandis que SAML y est une fonctionnalité Enterprise. Consultez la page d’authentification du projet concerné avant l’installation, car ces listes évoluent avec les releases.

Dois-je payer l’offre qui déverrouille le single sign-on ?

Prenez votre décision à partir de deux chiffres : le nombre de personnes qui ont besoin d’un compte et le nombre d’applications que vous devriez sinon administrer manuellement. Pour un ou deux administrateurs, le forward auth devant un compte local suffit et l’offre payante apporte peu. Dans une équipe où les arrivées et les départs sont fréquents, un compte oublié lors du départ d’un utilisateur coûte plus cher que la licence. Le paiement finance alors la maintenance dont vous dépendez. Si le prix ne convient pas, le choix le plus pratique consiste à utiliser une application qui inclut OIDC plutôt qu’à contourner les limitations d’une application qui ne le prend pas en charge.