De beste zelfgehoste CIAM voor B2B-SaaS-bouwers

Als je de prijzen van sommige SaaS-CIAM-platforms hebt bekeken, is je waarschijnlijk opgevallen hoe duur ze worden en heb je vermoedelijk al aan een zelfgehoste optie gedacht.

Dit artikel gaat over de vier zelfgehoste CIAM-platforms die een klein B2B-SaaS-team echt kan draaien zonder dat het een tweede fulltimebaan wordt: ZITADEL, FusionAuth, Logto en Ory Hydra. Ze hebben niet allemaal dezelfde vorm, en welke voor jou de juiste is hangt minder af van een functielijst en meer van het soort B2B-product dat je bouwt. Ik heb ze een week lang naast elkaar op één VPS gedraaid om deze vergelijking te maken, en wat volgt is de versie die ik zou sturen naar een oprichter die me een DM stuurt over CIAM.

Eén ding vooraf: dit gaat over CIAM als productfunctie, niet over interne SSO voor je eigen team.

De korte versie

Vier zelfgehoste CIAM-platforms, één regel per stuk:

• ZITADEL als je multi-tenancy en B2B-organisaties direct uit de doos wilt.
• FusionAuth als je een verzorgde beheerinterface en een lange, voorspelbare releasegeschiedenis wilt.
• Logto als je de schoonste developerervaring op dag één wilt.
• Ory Hydra als je op protocolniveau bouwt en de OAuth 2.0-engine wilt, geen kant-en-klare loginapp.

Kort gezegd: ZITADEL is de veiligste eerste keuze voor een doorsnee B2B-SaaS, en de rest van het artikel werkt die redenering uit.

Waarom CIAM een andere beslissing is dan interne SSO

Als de SSO voor je interne team uitvalt, blijft de schade meestal beperkt. Je engineers verliezen misschien een uur lang toegang tot Grafana of een ander intern hulpmiddel. Valt CIAM uit, dan kunnen je betalende klanten helemaal niet meer inloggen op het product. Daarmee verschuift de vraag van 'welke authenticatietool is handig voor ons team?' naar 'welk authenticatiesysteem kunnen we vertrouwen als onderdeel van het product zelf?'

CIAM, het soort identiteitsinfrastructuur dat een B2B-SaaS nodig heeft, vraagt ook om primitieven die veel interne SSO-tools niet benadrukken. Je klant is geen enkele gebruiker; het is een organisatie (een tenant) met eigen gebruikers, rollen, huisstijl en mogelijk een eigen SAML-koppeling naar een bedrijfs-IdP. Je authenticeert niet alleen mensen; je isoleert de gebruikers van het ene bedrijf van die van het andere binnen hetzelfde product. Dat is de B2B-vorm waar de vier tools hieronder elk op hun eigen manier op mikken. Keycloak heeft inmiddels volwaardige Organizations, dus het afdoen als alleen geschikt voor personeel is achterhaald; ik leg zijn afwezigheid uit in de FAQ.

De driehoek bouwen, kopen of zelf hosten ziet er hier ook anders uit. OAuth vanaf nul bouwen is een vermijdbare fout. Je levert een SaaS-product, geen identity provider. Managed kopen (Auth0, Clerk, WorkOS) is de juiste keuze als je team nul ops-capaciteit en een redelijk budget heeft. Ik zou een start-up van twee mensen nooit aanraden om auth op dag één zelf te hosten. Zelf hosten wordt rationeel zodra de MAU-prijs van managed CIAM de kosten van infrastructuur plus doorlopende engineeringtijd overstijgt, of wanneer je directe controle over de deployment en de data plane nodig hebt. In de teams waarmee ik heb gewerkt, valt dat punt meestal tussen 'we hebben een echt product' en 'we hebben een echte customer-successfunctie'.

Zoek je SSO voor je eigen applicaties in plaats van die van je klanten, dan is dat een andere vergelijking dan deze. Door naar onze favorieten.

De vier tools, één voor één

Ik koos deze vier omdat ze CIAM-vormig genoeg zijn om als productinfrastructuur te beoordelen, niet alleen als interne SSO. ZITADEL, FusionAuth, Logto en Ory bieden allemaal een echt zelfhostpad en genoeg tractie om serieus te overwegen. De opties die alleen een bibliotheek zijn, de workforce-SSO-oplossingen en de minder volwassen kandidaten komen beter in de FAQ aan bod.

ZITADEL

ZITADEL is een in Zwitserland gebouwd identiteitsplatform, geschreven in Go, met een event-sourced architectuur en PostgreSQL als backend. Per 27 juli 2026 is de nieuwste GitHub-release the 4.16 series, current as of July 2026. ZITADEL is vanaf v3 overgestapt van Apache 2.0 naar AGPL-3.0; voor normaal SaaS-gebruik valt de praktische impact meestal mee, en de details behandel ik in de FAQ.

Wat ZITADEL onderscheidt voor B2B-SaaS: organisaties en multi-tenancy zijn volwaardige primitieven, geen functies die je uit generieke objecten samenstelt. Je maakt een Organization aan, die krijgt eigen gebruikers, beleid, huisstijl en toegangsinstellingen, en je kunt er projecten aan toekennen zodat de beheerders ervan de rollen van hun eigen gebruikers regelen. Je hoeft het begrip 'tenant' niet bovenop generieke gebruikers te verzinnen. Je begint ermee.

De developerervaring is API-first, met de huidige v2 REST-resource-API's plus gRPC- en REST-toegang tot de oudere v1-services. Officiële en community-SDK's dekken de gangbare serverstacks. De beheerconsole is functioneel, maar soberder dan die van FusionAuth.

Mijn inschatting: Bouw je een B2B-SaaS en weet je dat je tenants krijgt, dan zou ik met ZITADEL beginnen. Van de zelfgehoste opties is dit degene die het duidelijkst rond het B2B-loginprobleem is gebouwd.

FusionAuth

FusionAuth is een Amerikaans platform van Inversoft, LLC (een LLC uit Delaware, handelend als FusionAuth) dat er langer is dan de andere drie, en dat merk je, in positieve zin. De beheerinterface voelt duidelijk beter ontworpen dan de rest, de documentatie is volwassen en het releaseritme is gestaag in plaats van halsbrekend. Heb je ooit een vier jaar oude auth-integratie geërfd en de vorige engineer stilletjes bedankt omdat die voor de saaie optie koos, dan is FusionAuth de CIAM-variant die dat bedankje verdient.

De licentie is waar mensen over struikelen: FusionAuth Community is gratis zelf te hosten, maar het kernproduct is geen open source. Het product valt onder de eigen licentie van FusionAuth, en die grenzen zijn belangrijk als je FusionAuth wilt herdistribueren, insluiten, herlabelen, doorverkopen of hosten voor je eigen klanten. De zelfgehoste Community-versie dekt het kernscenario van een B2B-SaaS; betaalde abonnementen voegen functies toe zoals IdP-geïnitieerde SAML, geavanceerde MFA en applicatiespecifieke thema's, terwijl SCIM, Tenant Manager en MFA-beleid op applicatieniveau in Enterprise zitten.

Over de B2B-vorm: FusionAuth modelleert tenants en applicaties, maar de abstractie is 'gecontaineriseerde auth per tenant' in plaats van 'B2B-organisaties als domeinobject'. Het werkt (ik heb er producten mee uitgebracht), maar de multi-tenancy voelt meer als een isolatieprimitief dan als een volwaardig B2B-model. De officiële SDK's en clientbibliotheken zijn breed:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

De serverbibliotheken zijn dunne API-clients. De beheerconsole is in vergelijking makkelijker over te dragen aan een ops-medewerker zonder engineeringachtergrond dan de andere.

Mijn inschatting: Hecht je team meer waarde aan een verzorgde interface en een lange, voorspelbare geschiedenis dan aan B2B-native primitieven, dan FusionAuth. Het is hier de 'saaiste' keuze, en dat is een compliment.

Logto

Logto is de jongste van de vier, ontwikkeld door Silverhand Inc. en gelicentieerd onder MPL-2.0, en het is degene die het duidelijkst geeft om zijn dashboard. De opzet op dag één gaat relatief snel. Je provisioneert, klikt door de wizard en hebt binnen een minuut of vijftien een werkende OIDC-provider met een prima standaard login-UI (ik heb het geklokt in de week dat ik alle vier naast elkaar draaide). De officiële quickstarts dekken moderne frameworks en serverstacks, dus als je stack 'Next.js + Postgres + iets' is, voel je je meteen thuis.

Zijn B2B-antwoord heet Logto Organizations. Het dekt de belangrijkste B2B-primitieven: organisatielidmaatschap, rollen binnen de organisatie, uitnodigingen voor leden, just-in-time provisioning en enterprise-SSO-integratie. Het organisatiemodel is jonger dan dat van ZITADEL, dus ik zou elke ongebruikelijke SAML-, SCIM- of federatiestroom testen bij je doelklanten voordat je je vastlegt.

De afweging is volwassenheid: Logto is hier de jongste optie. De roadmap gaat snel, wat prettig is als een functie die je nodig hebt landt, en oncomfortabel als er een breaking change landt. Zit je B2B-SaaS aan de eenvoudige kant van het multi-tenancy-spectrum (een kleine set organisaties en geen exotische federatie-eisen), dan maakt de developerervaring van Logto de rest van de beslissing makkelijker.

Mijn inschatting: Wil je de snelste eerste dag en zijn je B2B-behoeften nog relatief eenvoudig, dan Logto.

Ory Hydra (en de Ory-stack)

Ory Hydra is de OAuth 2.0 / OpenID Connect-server uit het Ory-ecosysteem, gelicentieerd onder Apache-2.0. De volledige Ory-stack koppelt Hydra aan Ory Kratos (identiteit en gebruikersbeheer, selfservice-login, registratie, MFA en accountherstel), Ory Keto (een autorisatieserver in Zanzibar-stijl die als policy decision point fungeert) en Ory Oathkeeper (een identiteits- en toegangsproxy die inkomende HTTP-verzoeken authenticeert, autoriseert en aanpast). Je stelt samen wat je nodig hebt. Alles is in Go geschreven en de API's zijn netjes.

De haak (en dat is geen gebrek; voor het juiste team is het een pluspunt) is dat Hydra de motor is, niet de applicatie. Van opzet verbindt Hydra met een aparte login- en consent-app die jij levert. Wil je een kant-en-klaar loginscherm, dan is dit niet het juiste hulpmiddel. Bouw je iets waarbij de auth-flow onderdeel is van je product (een developerplatform, een op maat gemaakt B2B-portaal of een API-first product met eigen onboarding), dan is juist het ontbreken van een opgelegde UI wat je wilt.

Het B2B-verhaal is samen te stellen in plaats van kant-en-klaar. Je kunt multi-tenancy modelleren door Kratos-schema's en Keto-relaties aan je eigen organisatielaag te koppelen, en dat werkt, maar het koppelen doe jij. De prijs is meer loodgieterswerk; de winst is controle over de ervaring. De documentatie van Ory behandelt het protocoloppervlak grondig, maar het samenstelbare model gaat ervan uit dat je zelf beslissingen op protocolniveau wilt nemen. Zeggen 'audience claim' of 'PKCE' je niets, begin dan met een van de andere drie.

Mijn inschatting: Bouw je iets op protocolniveau (auth-gateway, eigen flows, developerplatform) en voelen de standaardapplicaties beperkend, dan is Ory het juiste antwoord. Voor een doorsnee B2B-SaaS dat vandaag een werkende login wil, niet.

Zo verhouden ze zich in één oogopslag

Hier de samenvatting van de vier tools in één tabel, handig voor een tweede ronde, niet als vervanging voor de profielen hierboven.

Met welke moet je beginnen?

Vier korte scenario's die de meeste teams dekken waarmee ik hierover zou praten.

Je bouwt een B2B-SaaS en je weet dat je tenants krijgt. Begin met ZITADEL. De primitieven voor multi-tenancy en organisaties zijn hier precies voor gemaakt, het API-oppervlak is uitgebreid, en je bent minder tijd kwijt aan het uitvinden van het tenantmodel dan bij de andere drie. De overstap naar AGPL verdient een licentiecontrole, maar een ongewijzigde, apart geïntegreerde deployment is meestal een rechttoe rechtaan SaaS-scenario.

Je wilt de verzorgde beheerinterface en een stabiel, voorspelbaar platform. FusionAuth. Het Community-plan dekt de kernbehoeften van veel teams; reserveer tijd om de licentie en de functiematrix goed door te lezen. Functies als IdP-geïnitieerde SAML, geavanceerde MFA en applicatiespecifieke thema's vereisen een betaald plan, terwijl SCIM, Tenant Manager en MFA-beleid op applicatieniveau in Enterprise zitten.

Je B2B-behoeften zijn vandaag eenvoudig en je wilt de snelste eerste dag. Logto. De developerervaring op dag één was in mijn vergelijkende test de snelste. Accepteer dat je op een jonger ecosysteem gokt, en heroverweeg de keuze als je eisen uitgroeien tot federatie-randgevallen die je niet hebt getest.

Je bouwt iets waarbij auth-flows deel uitmaken van de productervaring. Ory Hydra (plus Kratos, plus Keto als je permissies nodig hebt). Je schrijft meer code. Je hebt meer controle. Is die ruil je niet duidelijk, dan ben je niet het publiek van Ory. Kies een van de andere drie.

Passen twee van deze beschrijvingen bij jou, kies dan standaard ZITADEL. Het past het breedst en is degene die ik een klein oprichtersteam zou geven zonder veel vervolgvragen te stellen.

Wat zelf hosten je kost (operationeel)

Nu het onromantische deel van dit artikel.

Je PostgreSQL-backupdiscipline is nu iets waar je bedrijf van afhangt. In deze deployments kan de identiteitsstatus die je moet beschermen bestaan uit gebruikersrecords, gehashte inloggegevens, MFA-secrets, OAuth-clientcredentials en sessiegegevens. Raak je die status kwijt, dan kunnen je klanten niet meer inloggen. Zet automatische back-ups op voordat je eerste echte gebruiker zich aanmeldt, test de restore, en zet de backupstatus in hetzelfde alertkanaal als je applicatie-uptime.

Het releasetempo verandert door de tijd heen. ZITADEL v4.16.1 verscheen op 17 juli 2026 na meerdere releases in juni, en elk project hier houdt zijn eigen cadans en compatibiliteitsbeleid aan. Behandel die cadans als een onderhoudsvraagstuk, niet als een snelle kwaliteitsmaatstaf. Lees de release notes voordat je docker compose pull draait, en plan een terugkerend patchvenster in. Maandenlang updates van je identity provider overslaan kan je bij je eerste echte review achterop zetten op beveiligings- en compatibiliteitsfixes.

De alledaagse dingen die je altijd besluipen: het vernieuwen van TLS-certificaten (gebruik een reverse proxy met Let's Encrypt, automatiseer verlengingen en alarmeer bij fouten), de configuratie van je uitgaande mailer voor verificatiemails en wachtwoordresets (SES, SendGrid, Postmark: kies er één en configureer SPF/DKIM/DMARC netjes, anders belanden je resetmails in de spam), het roteren van OAuth-clientcredentials als een engineer vertrekt, en rate limiting op de login-endpoints zodat een credential-stuffing-aanval je CPU niet vastzet.

Pro-tip: gebruik je managed Postgres, ga er dan niet vanuit dat de runtime-databasegebruiker ook het schema kan aanmaken. Maak de database en gebruiker vooraf aan, ken de vereiste eigenaars- of setuprechten toe, en draai de eerste setup met de credentials die elke tool verwacht. Anders kan je eerste run stuklopen op een vage databaserechtenfout en verbrand je een uur aan het verkeerde spoor.

Wat de zelfgehoste route je in dollars bespaart, kost je in eigenaarschap. Reserveer na de installatie een paar engineeringuren per maand om de identiteitslaag gezond te houden. Teams die nul tijd inplannen ontdekken de kosten meestal later: tijdens een storing, bij een raar SAML-randgeval of tijdens hun eerste securityreview.

Waar je ze uitrolt

Een Linux-VPS met Docker Compose kan een verstandig startpunt zijn voor evaluatie en bescheiden werklasten, maar productiedimensionering en hoge beschikbaarheid hangen af van verkeer, beveiligingseisen en je tolerantie voor downtime. Zo passen de gangbare deployment-opties:

• Gedeelde hosting kan er geen enkele draaien. Ze hebben persistente opslag nodig, eigen poorten, root-toegang voor de container-runtime en een echte databasebackend. PostgreSQL is voor het merendeel van deze lijst het standaardpad, maar het is niet letterlijk de enige ondersteunde database voor elke tool.
• Kubernetes kan alle vier draaien, maar het officiële pad is ongelijk. ZITADEL, FusionAuth, en Ory publiceren eigen Helm-charts, terwijl de zelfhostdocumentatie van Logto zich richt op Docker- en VM-deployment. Voor een kleine B2B-SaaS die het punt nog niet heeft bereikt waarop Kubernetes zich elders terugverdient, is het meestal over-engineering. Grijp ernaar zodra de rest van je infrastructuur er al draait.
• Bare metal is prima als je er al op zit. De meeste B2B-SaaS-teams zitten er niet op.

Voor een kleine single-node pilot zou ik starten met 4 GB RAM, 2 vCPU en 60 GB NVMe-opslag, en dan de echte loginflow loadtesten. Dat is een planningsbasis, geen universeel productieminimum. De applicaties zijn relatief licht, maar PostgreSQL heeft geheugen nodig en wachtwoordhashing heeft CPU-ruimte nodig. De productierichtlijnen van ZITADEL raden aan vier CPU-cores beschikbaar te houden voor pieken in wachtwoordhashing.

Zodra het product echt is en het verkeer aanhoudt, schaal je bij op basis van metingen. Snelle opslag helpt de PostgreSQL-latentie, terwijl CPU-ruimte telt tijdens gelijktijdige wachtwoordhashing. Houd geheugen, database-I/O, loginlatentie en CPU-verzadiging in de gaten in plaats van aan te nemen dat één resource het belangrijkst is.

CIAM in productie draaien betekent dat de uptime ervan nu jouw probleem is. Wij draaien Cloudzy Linux VPS instances voor dit soort werklasten, met NVMe-opslag en een uptime-SLA van 99,95% op het onderliggende platform. Cloudzy biedt daarnaast een ZITADEL-VPS met één klik als je het initiële provisioningscript liever overslaat; de andere drie leveren officiële container-images voor een Docker-opzet. Voor een managementblik op hoe toegangscontrole past in de rest van je securityhouding behandelt de gids met IAM-best practices gids het onderwerp vanuit de beleidskant.

Veelgestelde vragen

Heeft de AGPL-licentie van ZITADEL gevolgen voor mijn SaaS?

Meestal niet bij een ongewijzigde, apart geïntegreerde deployment, maar dit is geen juridisch advies. De AGPL-verplichtingen van ZITADEL gelden voor ZITADEL zelf. Wijzig je ZITADEL en draai je die gewijzigde versie als netwerkdienst, dan kan de licentie eisen dat je de bijbehorende broncode onder AGPL aanbiedt. Het gepubliceerde standpunt van ZITADEL is dat het enkel gebruiken van een ongewijzigde instance als identiteitsdienst voor je SaaS je op zichzelf niet verplicht je aparte applicatie onder AGPL te licentiëren. Lees de licentieaankondiging van ZITADEL en win juridisch advies in als je de software wijzigt, herdistribueert, insluit of aan derden aanbiedt. Er is ook een commerciële licentie beschikbaar.

Waarom staan Keycloak en Authentik niet op deze lijst?

Keycloak en Authentik zijn uitstekende zelfgehoste identiteitstools (ik gebruik ze), maar Keycloak uitsluiten omdat het geen B2B-organisaties zou hebben, klopt nu niet meer: huidige Keycloak-releases bevatten Organizations, organisatiegroepen en gedelegeerde beheerinstellingen. Ik heb het weggelaten omdat deze vergelijking zich richt op vier opties met een directer pad voor een klein B2B-SaaS-team; Keycloak verdient een eigen evaluatie wanneer JVM-beheer, diepte van het ecosysteem en flexibiliteit op realm-niveau tellen. Authentik past nog altijd beter bij workforce- en interne-app-SSO dan bij productnatieve tenantmodellering.

Is zelf hosten goedkoper dan Auth0?

Bij lage MAU-aantallen vaak niet. Je engineeringuren kosten meer dan de Auth0-rekening op het early-startup-niveau. Zelf hosten wint economisch op de schaal waar de MAU-prijs van managed CIAM de gecombineerde kosten van een kleine VPS plus die paar engineeringuren per maand overstijgt. Het exacte break-evenpunt hangt af van het uurtarief van je team, je MAU-groeicurve en of je product enterprise-functies nodig heeft die je naar de duurdere Auth0-niveaus duwen. Beschouw de besparing als echt, maar niet als onmiddellijk.

Wat is de minimale VPS-grootte voor een CIAM in productie?

Voor een kleine single-node pilot zijn 4 GB RAM, 2 vCPU en NVMe-opslag een redelijk startpunt, geen productiegarantie. Dimensioneer op basis van je databaseomvang, gelijktijdige loginbelasting, de kosten van wachtwoordhashing en je uptimedoel. De eigen productierichtlijnen van ZITADEL adviseren vier CPU-cores beschikbaar te hebben voor hashingpieken; andere tools en verkeerspatronen vragen om hun eigen loadtests.

Kan ik later van een managed CIAM naar zelf hosten migreren?

Ja, maar plan het als een echt project. Wachtwoordresets zijn niet onvermijdelijk: exporteerbaarheid en ondersteunde hashformaten verschillen, en sommige doelen ondersteunen bulk- of just-in-time-gebruikersmigratie terwijl andere een reset afdwingen. MFA-factoren, OAuth-clients, actieve sessies, de e-mailverificatiestatus en tenant- of rolmappings vragen om aparte behandeling. Vermoed je nu al dat je later zelf gaat hosten, leg die export- en migratiebeperkingen dan vast voordat je de managed provider kiest.