SSO-belasting bij zelfgehoste software uitgelegd

Wat de SSO-belasting inhoudt

De SSO-belasting bij zelfgehoste software is het patroon waarbij de applicatie gratis is, maar single sign-on (SSO) de enige functie is waarvoor u moet betalen. U kunt het volledige pakket op uw eigen VPS draaien zonder licentiesleutel of beperking op het aantal gebruikers. Vervolgens opent u de authenticatiepagina in de documentatie en ziet u dat OpenID Connect (OIDC) of SAML (security assertion markup language) onder een betaald abonnement valt.

Dit is belangrijker dan een gewone functie achter een betaalmuur, omdat SSO ervoor zorgt dat een verzameling zelfgehoste services zich als één systeem gedraagt. Een identity provider (IdP) biedt u één account per persoon, één wachtwoordbeleid, één plek om multi-factor authentication (MFA) in te schakelen en één plek om de toegang voor iemand in te trekken. Zonder dit systeem houdt elke app een eigen kleine gebruikersdatabase bij en moet u elke database handmatig onderhouden.

Dit patroon is oud genoeg om een openbare ranglijst te hebben. De SSO Wall of Shame op sso.tax somt leveranciers op die een grote meerprijs vragen voor single sign-on, met vermeldingen die teruggaan tot 2018. De auteur hanteert een redelijke norm: "Als uw SSO-ondersteuning een prijsverhoging van 10% betekent, staat u niet op deze lijst." Het grootste deel van die lijst bestaat uit propriëtaire software. Dezelfde prijslogica duikt nu op in open source-projecten die u zelf host.

Waarom beheerders single sign-on achter een betaalde laag plaatsen

Er zijn twee redenen en beide zijn legitiem. SSO is duur om te ondersteunen en het is een van de weinige functies waar een grote organisatie voor wil betalen.

De ondersteuningskosten zijn reëel omdat een identiteitsintegratie nooit af is. Elke IdP formatteert zijn claims net even anders. Groepstoewijzing, sessieduur, redirect-URL's en klokafwijkingen veroorzaken elk inlogfouten, en een inlogfout sluit direct alle gebruikers tegelijk uit, waardoor deze tickets urgent zijn. Daarna volgen de vervolgverzoeken: geneste groepen, roltoewijzing, automatische provisioning met SCIM (system for cross-domain identity management) en auditlogs die door een compliance-team worden gelezen.

De inkomstenkant is een kwestie van rekenkunde in plaats van kwade opzet. Een bedrijf dat de applicatie niet kan koppelen aan zijn eigen IdP, zal deze helemaal niet implementeren. SSO vormt dus een duidelijke grens tussen de gebruiker die betaalt en de gebruiker die dat niet doet. Een open-coreproject moet die grens ergens trekken. SSO past daar beter dan bijna elke andere functie, en dat is de reden waarom zoveel projecten hiervoor kiezen.

Eén correctie op de gebruikelijke klacht: controleer de changelog voordat u aanneemt dat een functie is verwijderd, want een verwijdering staat in de release notes. Bij de projecten die ik voor dit artikel heb gecontroleerd, waren de betaalde SSO-functies vanaf het begin gebouwd voor de betaalde laag. Ik heb geen enkel geval gevonden waarin werkende gratis SSO werd ingetrokken. Grafana is hier een typerend voorbeeld. De SAML-pagina bevat een opmerking van één regel: "Available in Grafana Enterprise and Grafana Cloud", terwijl generieke OAuth tegen uw eigen issuer gewoon werkt in de open-sourceversie.

Wat de SSO-belasting u werkelijk kost

Het geld is slechts de helft van het probleem. Betaalde abonnementen worden per gebruiker verkocht, waardoor de rekening stijgt naarmate uw team groeit, terwijl het beheer en de updates uw verantwoordelijkheid blijven.

De grootste kostenpost is het handmatige identiteitsbeheer, en dit uit zich op vier gebieden.

• Eén wachtwoordkluis per applicatie; een hergebruikt wachtwoord vormt daardoor een beveiligingslek in elke applicatie die dit wachtwoord deelt.
• Offboarding op basis van geheugen. U moet onthouden met welke services een medewerker heeft gewerkt, en juist de service die u vergeet, is vaak de meest kritieke.
• MFA moet per applicatie worden geconfigureerd, voor zover de applicatie dit überhaupt ondersteunt.
• Gedeelde inloggegevens; dit is wat er in kleine teams onder deze druk in de praktijk gebeurt.

Dat laatste punt verdient extra aandacht. Wanneer een team één beheerdersaccount deelt in een documentbeheersysteem, registreert het auditlogboek voor elke actie dezelfde naam. Hierdoor is het onmogelijk te achterhalen wie bijvoorbeeld een factuur heeft verwijderd. Ook rechten op gebruikersniveau werken niet meer, omdat er slechts één gebruiker is. Dat is de werkelijke schade van de SSO-belasting: het dwingt kleine teams naar een enkel gedeeld account, wat de slechtste optie van allemaal is.

De checklist die u moet doorlopen voordat u iets in gebruik neemt

Voer dit uit vóór docker compose up, niet nadat de applicatie al 400 documenten bevat.

1. Open de authenticatiepagina in de documentatie en lees de opmerking over de licentielaag bovenaan. Betaalde functies zijn voorzien van een badge of een zin die de beschikbaarheid aangeeft.
2. Bevestig dat de applicatie OIDC of SAML spreekt met uw eigen issuer, in plaats van met een vaste lijst van publieke providers.
3. Controleer de mapping van rollen en groepen. Het aanmaken van de gebruiker is slechts de helft van het werk; het handmatig toewijzen van rechten in tien verschillende applicaties is het pijnlijke deel.
4. Controleer of de applicatie een geauthenticeerde gebruikersnaam accepteert via een header van een vertrouwde proxy, en of u kunt vastleggen welke proxy wordt vertrouwd.
5. Lees de licentiegeschiedenis in git en controleer of bijdragers een CLA (contributor licence agreement) ondertekenen.
6. Controleer de offboarding-procedure. Zoek uit wat er gebeurt met API (application programming interface) tokens en actieve sessies wanneer het IdP-account wordt uitgeschakeld.

Punt 2 is waar de meeste teleurstellingen ontstaan. Een "Sign in with Google"-knop is geen OIDC met uw eigen identity provider: het is een vaste integratie met één specifieke leverancier. Echte ondersteuning vraagt om een issuer URL, waarna de rest via discovery wordt opgehaald. U kunt de kant van uw provider hiervan met één commando bevestigen.

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

Bij een correct werkende provider krijgt u drie URL's terug. Een leeg resultaat of een 404 betekent meestal dat het discovery-pad onjuist is; dit pad is provider-specifiek: Keycloak publiceert dit onder /realms/<realm>/.well-known/openid-configuration. Als de applicatie helemaal geen veld heeft voor een issuer URL, kan deze niet communiceren met uw IdP, ongeacht wat de lijst met functies beweert.

Punt 6 zorgt vaak voor problemen weken nadat iemand de organisatie heeft verlaten. Het uitschakelen van het account in de IdP stopt nieuwe aanmeldingen. Het trekt echter geen API-token in dat de applicatie eerder heeft uitgegeven, omdat de applicatie dat token zelf valideert en nooit navraag doet bij de IdP. Offboarding bestaat daarom uit twee stappen: schakel het account uit in de IdP en verwijder vervolgens de gebruiker of de bijbehorende tokens in elke applicatie.

Wat de tier-badges daadwerkelijk betekenen

Deze worden in augustus 2026 getoetst aan de documentatie van elk project. Begin bij de betaalde varianten.

Grafana publiceert SAML als "Beschikbaar in Grafana Enterprise en Grafana Cloud", samen met team-sync en SCIM-provisioning. Generieke OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) en de auth proxy zitten allemaal in de open-source build, dus een kleine zelf-hoster kan nog steeds inloggen via een eigen provider. De betaalde grens ligt bij SAML en niet bij single sign-on in zijn geheel; dit is de nuance die de term "SSO-belasting" vaak negeert.

Metabase is directer. De documentatie stelt: "SAML-authenticatie is alleen beschikbaar in Pro- en Enterprise-abonnementen (zowel self-hosted als op Metabase Cloud)." De open-source editie behoudt wachtwoordinlog en LDAP.

Passbolt markeert zijn SSO-documentatie als Pro en Cloud, dus de community-editie beschikt hier niet over. De gedocumenteerde providers omvatten Keycloak en Entra ID.

Nu de andere kant, aangezien dit patroon verre van universeel is.

• GitLab Self-Managed vermeldt "Tier: Free, Premium, Ultimate" op de SAML-pagina, dus SAML gebruiken met uw eigen GitLab kost niets.
• Paperless-ngx configureert OIDC via django-allauth met PAPERLESS_SOCIALACCOUNT_PROVIDERS, verbergt het lokale inlogformulier met PAPERLESS_DISABLE_REGULAR_LOGIN en koppelt claims aan groepen met PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• Planka gebruikt OIDC_ISSUER, OIDC_CLIENT_ID en OIDC_CLIENT_SECRET, stelt de scopes standaard in op openid profile email en bevordert beheerders op basis van een rol-claim met OIDC_ADMIN_ROLES.
• BookStack schakelt over met AUTH_METHOD=oidc en koppelt vervolgens groepen van de provider aan eigen rollen met OIDC_USER_TO_GROUPS=true en OIDC_GROUPS_CLAIM.
• Vaultwarden bracht "ondersteuning voor SSO met OpenID Connect" uit in 1.35.0 op 27 december 2025, afkomstig uit een pull request van een bijdrager die de functie in een fork had onderhouden.
• listmonk heeft sinds v4.0.0 OIDC-inlog naast de gebruikersrollen.

Gebruik deze informatie bij het maken van uw keuze, in plaats van nadat u zich al heeft vastgelegd. Een Planka kanban-bord en de andere zelf-gehoste Trello-alternatieven gaan niet allemaal op dezelfde manier om met identiteit, en dat geldt ook voor BookStack, Wiki.js en Outline. Gratis OIDC is een functie die u kunt meewegen, net als opslaglimieten of mobiele clients. Als u nog bezig bent met het opstellen van de lijst, is wat te zelf-hosten in 2026 een redelijk startpunt, en zowel de Paperless-ngx documentmanager als Vaultwarden bieden u vandaag gratis OIDC.

Waarom een reverse proxy voor een applicatie geen single sign-on is

De gebruikelijke oplossing is forward auth. Uw reverse proxy houdt elk verzoek vast, vraagt aan een authenticatiedienst of deze browser is ingelogd en stuurt het verzoek pas daarna door naar de applicatie. authentik noemt dit een proxy provider, met een forward auth-modus voor een enkele applicatie en een andere voor een volledig domein. Authelia en oauth2-proxy vervullen dezelfde taak.

Een Caddy site block ziet er als volgt uit, volgens het eigen voorbeeld van 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
}

Hoofdlettergebruik van die headernamen is in Caddy van belang, omdat een afwijkende naam leeg aankomt. Bij elk goedgekeurd verzoek stelt de outpost X-authentik-username, X-authentik-email, X-authentik-groups en enkele andere in.

Dit is wat u hiermee bereikt. Niemand bereikt de applicatie zonder eerst langs uw identity provider te gaan, waardoor een ongepatcht inlogformulier niet langer is blootgesteld aan het internet en MFA direct van toepassing is op alles achter de proxy.

Dit is wat u er niet mee bereikt: identiteit binnen de applicatie. De applicatie heeft nog steeds haar eigen accounts en haar eigen beeld van wie er is ingelogd. Als iedereen de proxy passeert en op één gedeeld administrator-account terechtkomt, heeft u een sterke voordeur en één anonieme sessie daarachter. Het auditlogboek toont nog steeds één naam. Rechten kunnen nog steeds niet verschillen per persoon. Die opzet SSO noemen is een beveiligingsfout, omdat het verhaal over offboarding slechts voor de helft klopt: het verwijderen van de persoon uit uw IdP sluit de voordeur, terwijl een API-token dat zij binnen de applicatie hebben aangemaakt blijft werken voor iedereen die de applicatie rechtstreeks kan bereiken.

Header-authenticatie veilig maken

Sommige applicaties accepteren een gebruikersnaam van de proxy, wat u identiteitsbeheer per gebruiker biedt zonder betaalde SSO. De instelling hiervoor heeft in elk project een andere naam.

Grafana noemt dit de auth proxy en levert deze standaard uitgeschakeld. De standaardnaam voor de header is X-WEBAUTH-USER, en u kunt deze verwijzen naar de header die uw proxy instelt.

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

whitelist is de regel die vaak wordt overgeslagen. De documentatie van Grafana is expliciet over het feit dat deze instelling dient om te voorkomen dat gebruikers de header vervalsen; deze moet daarom uitsluitend het adres van uw proxy bevatten. Gitea heeft dezelfde functionaliteit onder andere namen en hanteert standaard een veiligere configuratie.

[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 staat standaard op 127.0.0.0/8,::1/128, en REVERSE_PROXY_LIMIT bepaalt hoeveel proxy's Gitea in de keten vertrouwt. Door deze limiet op nul in te stellen, wordt de header-verwerking volledig uitgeschakeld.

Paperless-ngx biedt PAPERLESS_ENABLE_HTTP_REMOTE_USER met PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME, en de documentatie bevat de waarschuwing die voor al deze instellingen geldt:

Dit staat authenticatie toe door simpelweg een Remote-User: <username>-header aan een verzoek toe te voegen. Gebruik dit met zorg!

Twee regels houden header-authenticatie veilig, en beide hebben betrekking op de bereikbaarheid. Ten eerste moet de applicatie onbereikbaar zijn, behalve via de proxy, omdat iedereen die een socket naar de applicatie kan openen, die header kan meesturen en zich als elke willekeurige gebruiker kan voordoen. In Docker publiceert ports: ["8000:8000"] op elke interface; bind deze daarom aan het loopback-adres met ports: ["127.0.0.1:8000:8000"], of verwijder de gepubliceerde poort en plaats de proxy in hetzelfde Docker-netwerk. Ten tweede moet de proxy elke kopie van de header die van de client afkomstig is verwijderen, zodat de applicatie uitsluitend de waarde ziet die uw proxy na authenticatie instelt.

Controleer beide punten. Voer het eerste commando uit vanaf een machine buiten uw VPS en het tweede op de server zelf.

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

De curl-opdracht moet falen om verbinding te maken, en ss moet 127.0.0.1:8000 retourneren in plaats van 0.0.0.0:8000. Een eerste regel met HTTP/1.1 302 Found betekent dat de applicatie direct antwoordt op het publieke internet, waardoor iedereen kan inloggen als elke gebruiker door hun naam in een header op te geven.

Wanneer er geen gratis SSO beschikbaar is, neem dan een besluit in plaats van te klagen

Vier opties, in de volgorde waarin ik ze zou proberen.

1. Kies de applicatie die OIDC ondersteunt. Wanneer twee projecten hetzelfde doen en één daarvan gratis met uw identiteitsprovider communiceert, is dat een reëel verschil in operationele kosten.
2. Gebruik forward auth op een eerlijke manier. Voor een beheertool met één account en één beheerder is een proxy aan de voorzijde voldoende; identiteitsbeheer per gebruiker binnen de applicatie voegt in dat geval niets toe.
3. Betaal ervoor. Als de applicatie essentieel is voor uw werk en de prijs per gebruiker past bij uw teamgrootte, zorgt het geld voor het onderhoud van het project. Het alternatief is dat u de kosten betaalt in uw eigen avonduren.
4. Vraag het aan de ontwikkelaars, nadat u de issue tracker heeft doorzocht. De OIDC-ondersteuning van Vaultwarden kwam tot stand via de fork van een bijdrager en een langlopende pull request. Een feature request met een werkende implementatie erachter wordt soms wel degelijk opgenomen in de gratis editie.

Niets hiervan werkt zonder een eigen identiteitsprovider; dat is het onderdeel dat u als eerste moet opbouwen. Het draaien van authentik op een VPS levert u een OIDC- en SAML-provider op, inclusief de hierboven genoemde forward auth-outpost. De vergelijking tussen Keycloak, authentik en Zitadel behandelt de afwegingen als u zich nog niet wilt vastleggen.

Licentiegeschiedenis en waarom deze op de checklist staat

Het laatste punt op de checklist gaat over de toekomst, omdat de huidige indeling in lagen slechts een momentopname is. Twee goed gedocumenteerde gevallen laten zien hoe snel de situatie kan veranderen, in beide richtingen. HashiCorp nam op 10 augustus 2023 de Business Source License 1.1 aan voor alle toekomstige releases, terwijl eerdere releases onder de MPL 2.0 (Mozilla Public License) bleven vallen. Redis stapte in maart 2024 over op de SSPL (Server Side Public License) en kondigde op 1 mei 2025 aan dat Redis 8 ook onder de AGPLv3 (GNU Affero General Public License) wordt uitgebracht.

Beschouw beide gevallen als bewijs voor het mechanisme in plaats van het motief. De licentie die u vandaag leest, is van toepassing op de versie die u vandaag installeert, en een project dat alle auteursrechten in eigen beheer heeft, kan de voorwaarden van de volgende release eenzijdig wijzigen. Daarom staat de CLA-vraag op de checklist; een brede overdracht van auteursrechten is namelijk wat een eenzijdige licentiewijziging mogelijk maakt.

Controleer zelf de geschiedenis van een project voordat u erop voortbouwt.

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

Een korte lijst met commits, meestal afkomstig van de eerste import, is een goed teken. Meerdere herschrijvingen van het licentiebestand betekenen dat u elk commit-bericht moet lezen voordat u uw plannen baseert op de huidige voorwaarden.

FAQ

Wat is de SSO-belasting?

De SSO-belasting is de praktijk waarbij kosten in rekening worden gebracht voor single sign-on als een premiumfunctie, terwijl de rest van het product gratis of goedkoop is. Bij zelfgehoste software ziet dit eruit als een open-sourceapplicatie die u zonder licentiesleutel kunt draaien, waarbij OIDC- of SAML-login in een betaalde laag zit. De naam komt van de SSO Wall of Shame op sso.tax, die leveranciers bijhoudt die hiervoor een grote meerprijs vragen. Het gevolg voor een zelfhoster is dat elke app zijn eigen gebruikersdatabase bijhoudt, waardoor accounts handmatig moeten worden aangemaakt en verwijderd.

Is een reverse proxy met forward auth hetzelfde als SSO?

Nee. Forward auth beschermt de voordeur: uw proxy controleert bij de identiteitsprovider voordat een verzoek de app bereikt. De app erachter gebruikt nog steeds zijn eigen accounts; als iedereen op één gedeelde login terechtkomt, krijgt u één anonieme sessie en een auditlogboek met slechts één naam erin. Het wordt pas echte identiteit per gebruiker wanneer de app de gebruikersnaam uit een header leest, wat de auth proxy van Grafana, de reverse proxy-authenticatie van Gitea en de PAPERLESS_ENABLE_HTTP_REMOTE_USER van Paperless-ngx allemaal kunnen. Die instellingen zijn alleen veilig zolang de app niet bereikbaar is behalve via de proxy, omdat de header een platte tekstreeks is die elke client kan verzenden.

Welke zelfgehoste apps bevatten OIDC in de gratis editie?

Gecontroleerd aan de hand van projectdocumentatie in augustus 2026: Paperless-ngx, Planka, BookStack, Gitea, listmonk en Vaultwarden ondersteunen allemaal OIDC in hun gratis builds, en GitLab Self-Managed vermeldt SAML onder Tier: Free. De open-sourcebuild van Grafana verwerkt generieke OAuth tegen uw eigen issuer, terwijl SAML daar een Enterprise-functie is. Controleer dit op de eigen authenticatiepagina van het project voordat u installeert, omdat deze lijsten veranderen bij releases.

Moet ik betalen voor de laag die single sign-on ontgrendelt?

Bepaal dit aan de hand van twee getallen: hoeveel mensen hebben accounts nodig en hoeveel apps zou u anders handmatig onderhouden? Voor één of twee beheerders is forward auth voor een lokaal account voldoende en biedt de betaalde laag weinig meerwaarde. Voor een team waar mensen komen en gaan, kost één vergeten account bij het offboarden meer dan de licentie, en de betaling financiert het onderhoud waar u op vertrouwt. Als de prijs niet past, is de praktische keuze om een app te kiezen die OIDC bevat in plaats van een workaround te bouwen voor een app die dat niet doet.