Waarom je niet je eigen authenticatiesysteem zou moeten bouwen: lessen uit tientallen klantinterviews

Authenticatie lijkt iets wat je zo zelf in elkaar zet. E-mail, wachtwoord, hash het, vergelijk bij inloggen. Hoe moeilijk kan het zijn om je eigen authenticatiesysteem te bouwen?

Dat kun je. Dat is juist de valkuil.

We spraken met tientallen teams over de auth die ze zelf hadden gebouwd. De meesten kwamen bij ons om dezelfde reden: het hield het bedrijf tegen.

Verschillende sectoren, stacks en groottes, maar hetzelfde einde. De auth die ze gebouwd hadden, was een schuld geworden die het team met zich meedroeg.

Het vreemde is dat het nooit als een storing naar voren komt. Het systeem logt mensen in en draait prima, tot er een zakelijke verandering komt: een securityreview, de eerste enterprise-klant, een overname, een feature die twee producten moet overspannen.

Vorige week was het nog "prima." Dan is het volgende op de roadmap geblokkeerd.

De grootste fout met zelfgemaakte auth is het behandelen als een feature. Je kunt het op dag één schrijven. Maar als er echt verkeer doorheen loopt, raakt het verstrikt met je gebruikers, organisaties en permissies.

Authenticatie is geen feature. Het is identiteitsinfrastructuur.

Achter de inlogpagina zit een heel identiteitsmodel#

Elk zelfgebouwd auth-systeem begint hetzelfde. Neem een e-mail en wachtwoord, hash het, sla het op, vergelijk bij inloggen. Veertig regels code, schoon en klaar.

De problemen beginnen na de lancering. Bots bestoken de signup-endpoint, dus voeg je rate limiting toe, een CAPTCHA, device fingerprinting. SMS'jes gaan op een ochtend niet meer uit, dus voeg je retries en een dagelijkse limiet toe. Dan komen de lastigere onderdelen: veilig wachtwoordherstel, MFA en het recovery-proces, sessies en refresh tokens, en een permissiemodel dat meer is dan alleen een is_admin boolean.

Geen van deze zaken is op zich moeilijk. Elk past in een sprint. Maar elke keer dat je er één toevoegt, geef je een groter antwoord namens het product.

Stapel die antwoorden op en je krijgt het identiteitsmodel waar je product nu stilzwijgend vanuit gaat: wie telt als gebruiker, of één persoon bij meerdere organisaties mag horen, hoe het identity-systeem van een klant aansluit, en hoe toegang wordt ingetrokken als iemand vertrekt.

Elke feature die je daarna schrijft, neemt die antwoorden als vaststaand, en hoe langer het draait, hoe moeilijker ze zijn te veranderen.

We zagen dit bij één bedrijf: een verticale B2B SaaS, twintig jaar in business, actief in de fysieke retail. Ze bouwden hun eigen auth meer dan tien jaar geleden, met een aparte login per klant en permissiecontroles direct in de businessmodules. Destijds logisch.

Twintig jaar later wilden ze iets dat klein leek: één uniforme loginpagina, met e-mail als gebruikersnaam. Het was helemaal geen visuele wijziging. Die controles zaten verspreid over honderden modules, en inloggen unificeren betekende het gebruikersmodel, het organisatiemodel, credential-migratie en élke permissiegrens aanpassen. Niemand wilde daar z'n handtekening onder zetten, dus het sleepte zich jarenlang voort.

Toen ze die eerste loginpagina schreven, leek het een feature. Maar het liet een hele identiteitslaag achter.

Als je bedrijf verder groeit, is eigen auth vaak niet meer genoeg#

Eerlijk is eerlijk: zelfgemaakte auth werkt meestal jarenlang. Het logt mensen in, vernieuwt sessies en draait de dagelijkse business. De complexiteit stapelt zich langzaam op, nooit in één keer, en je handelt het steeds beetje bij beetje af, met het idee dat je het in de hand hebt.

Maar "voldoende" zijn betekent vaak alleen dat het bedrijf de muur nog niet heeft geraakt. Als dat wel gebeurt, is het probleem meestal niet de auth zelf. De business ernaast verschoof, en "voldoende" verandert ineens in "zit in de weg".

De volgende situaties komen bij de meeste producten terug als ze schalen. Ze lijken verschillend, maar ze komen op hetzelfde neer: het bedrijf beweegt vooruit, en het oude identiteitsmodel kan het tempo niet aan.

Enterprise-klanten willen SSO#

De situatie: een klant wil inloggen via hun eigen IdP, en jouw auth-systeem weet niets van "andermans identity provider".

De eerste echte enterprise-deal valt binnen en het inkoopteam stuurt een eisenlijst. Eerst is het SSO via Microsoft Entra of Google Workspace. Dan zowel SAML als OIDC, want de volgende klant gebruikt weer iets anders. Dan SCIM om medewerkers automatisch te (de)provisionen.

Elke klant werkt anders: andere protocollen, veldmapping, certificaatrotatie, en andere manieren waarop hun organisatiestructuur overeenkomt met die van jou.

En vrijwel niets daarvan is herbruikbaar. De volgende klant brengt een andere IdP en een nieuwe config, en je begint telkens deels opnieuw. SSO is geen feature die je één keer bouwt. Elke grote klant die je tekent, bouw je weer opnieuw — en het wordt alleen maar duurder naarmate je meer klanten hebt.

Auth is niet meer "laat gebruikers in je product inloggen". Het is "laat je product aansluiten op het identity-systeem van je klant". Twee totaal verschillende taken.

We zagen een bedrijf waar het hele SSO-proces met de hand ging, en precies één engineer het volledig begreep. Was hij er, dan gingen klanten live. Was hij weg, stonden sales en onboarding in de wachtrij. Toen hij vertrok, was de kennis ook weg.

Dit stond allemaal niet op tafel toen ze besloten zelf auth te bouwen.

Het product moet verspreide identiteit unificeren#

De situatie: je identiteitsdata begon gefragmenteerd, gesplitst per organisatie of product, en als het bedrijf groeit heb je één uniforme identiteit nodig.

Het twintigjarige bedrijf hierboven liep hier tegenaan toen ze login wilden samenvoegen, en hetzelfde kom je overal tegen. We werkten met een platform met negen producten, allemaal via overnames, elk met eigen auth en user store.

Een overname voegt die niet automatisch samen. Elk product dat je koopt, brengt een compleet nieuwe auth-stack met zich mee, en negen tegelijk onderhoudt zichzelf niet.

De vragen stapelen zich op. Is dezelfde persoon één gebruiker in product A en B, of twee? Hoe koppel je dezelfde klantorganisatie tussen beide? Hoe autoriseer je een cross-product feature? Als een medewerker vertrekt, hoe trek je overal tegelijk toegang in? En waar kun je dat allemaal auditen?

Geen van die negen systemen is stuk. Samen vormen ze een muur.

"Identiteit unificeren" klinkt als een feature. Maar in code betekent het het meest fundamentele opnieuw definiëren: wat is een gebruiker, wat een organisatie. Bijna elke feature leunt op de oude definitie, dus alles erboven moet ook mee.

In het AI-tijdperk hebben agents en CLI's toegang namens een gebruiker#

De situatie: het zijn niet alleen mensen die inloggen via een browser. Agents, commandlines en scripts zeggen nu allemaal dat ze namens een gebruiker handelen, terwijl je auth alleen "persoon logt in op pagina" kent.

Een agent moet interne tools aanroepen namens een gebruiker. Een MCP-server moet beveiligde resources tonen. Een CLI wil toegang tot accountdata zonder browser.

Alle drie lopen ze tegen dezelfde vragen aan: namens welke gebruiker handelt dit verzoek, welke resources mag het aanspreken, aan wie is de token uitgegeven, wat is het bereik, hoe trek je hem in, log je de gebruiker of de agent?

Het oude systeem bevatte die mechanismen niet. MCP vertrouwt op OAuth voor autorisatie. Een CLI gebruikt OAuth-login of een persoonlijk toegangstoken dat namens een persoon kan worden ingetrokken. Daar was je loginpagina niet voor gemaakt.

Als je auth ontworpen is voor één persoon die via een pagina inlogt, dan is dit het moment om clients namens die persoon te kunnen laten opereren.

Onderhoud op lange termijn is de grootste kost van eigen auth#

Geen van de bovenstaande situaties is "auth kapot". Het systeem draait nog steeds. Elk lijkt een kleine feature, maar als je eraan begint, blijkt het productstrategie, datamigratie en klantimplementatie.

MFA is het duidelijkste voorbeeld. Op het eerste gezicht: "kunnen we nogmaals verifiëren na inloggen?"

Twee stappen verder: voor welke organisaties en gebruikers is het verplicht, kan een admin het afdwingen voor leden, moeten gevoelige handelingen (zoals betaalinfo wijzigen of data exporteren) opnieuw gecontroleerd worden, hoe genereer en reset je recovery codes, kan support dat doen, en hoort de MFA van een SSO-gebruiker bij jou of bij de klant-IdP? MFA toevoegen is een complete laag securitybeleid toevoegen.

"Gewoon wat gebruikers syncen" is hetzelfde verhaal: daarachter zitten een reeks beslissingen over onboarding, offboarding en cross-org lidmaatschap, allemaal gebaseerd op je initiële user/organisatie-model.

Hoe meer je toevoegt, hoe meer je een identiteitsproduct in je eigen product onderhoudt. De eerste versie is goedkoop: paar engineers, paar weken. Maar je voedt het jaar na jaar.

De verborgen kosten: de rekening verandert alleen van vorm#

De meest genoemde reden om het zelf te bouwen zijn de kosten, en dat is niet naïef.

Een ledenorganisatie die we spraken rekende het vijf jaar geleden uit: honderdduizend leden, maar slechts een paar duizend logden regelmatig in. Leveranciers rekenen per totaal aantal leden, de offerte was te hoog, dus zelf bouwen was goedkoper. In dat jaar geen slechte keuze.

Vijf jaar later was het plaatje omgekeerd. Zelf onderhouden en veilig houden kostte al meer dan aanschaffen.

In jaar één is de bespaarde factuur zichtbaar en de engineer-tijd niet. In jaar vijf is die vermeden factuur hetzelfde, maar de ingenieurstijd is nu roadmap-vertraging, securityschuld en onderhoud dat niemand wil.

Eigen auth bouwen is dus niet gratis. Je krijgt alleen nooit een factuur met "authenticatie-abonnement" erop. Je betaalt in mensuren, gemiste deadlines, herbouwen, securityschuld en aandacht die naar je echte product had mogen gaan.

Een paar engineers zijn uiteindelijk allesbepalend#

Die engineer die SSO handmatig beheert is geen uitzondering. Zelfauth lang genoeg draaien, en de kritieke context zit bij één of twee mensen: welke klant is hoe geconfigureerd, welk veld mag je niet aanpassen, waarom die migratie zo ging. Het komt zelden in de documentatie terecht. Het leeft in iemands hoofd.

Is die persoon aanwezig, dan gaat levering door. Is hij dat niet, staat de enterprise-pijplijn stil, en blijkt dat je belangrijkste infrastructuur geen eigenaar heeft — alleen "de persoon die het weet."

Sommige teams bouwen zelfs een full self-serve SSO-platform voor klanten. Klinkt volwassen, tot je vraagt voor hoeveel klanten het dient. We zagen een systeem met 1,5 miljoen maandelijkse gebruikers, en alles draaide voor maar een dozijn enterprise-klanten.

Je dacht dat je een feature bouwde. Je was een intern product aan het bouwen, met de kosten uitgesmeerd over een handjevol klanten. Is identiteit je core business, dan loont dat. Zo niet, dan is het de zuiverste verborgen factuur.

Waar wil je je engineers op inzetten?#

Terug naar het twintigjarige verticale SaaS-bedrijf. Het zijn geen slechte engineers. Twintig jaar een brancheproduct in leven houden, bewijst juist dat ze hun klanten begrijpen.

Dat is precies het probleem. Plat gezegd: wil je dat ze handmatig aan elke klant hun SSO blijven sleutelen en twintig jaar permissielogica uit honderden modules trekken, of juist dieper in de brancheoplossing zelf duiken?

Dit is geen engineering-perfectionisme. Het is resource-allocatie. Bouw je bill pay, vertical SaaS, een ledenportaal of branchesoftware, dan betaalt geen klant jou extra omdat je je eigen OAuth-server geschreven hebt.

Een bill-payteam verwoordde het zo: hun eigen IdP was prima, maar het is een strategische keus. Bouw weinig zelf aan auth. Bewaar je energie om bill pay de beste te maken, en kies de meest bewezen auth voor de rest.

Auth moet betrouwbaar zijn. Maar "betrouwbaar" hoeft niet hetzelfde te zijn als "door jezelf gebouwd." Je database, maildelivery en cloud moeten óók betrouwbaar zijn, maar een volwassen team gaat er niet vanzelf vanuit dat zoiets per se intern moet zijn alleen omdat het belangrijk is.

Voor de meeste producten is auth een kern-afhankelijkheid, geen onderscheidend vermogen. Tenzij identiteit je business is, is een intern identiteitsproduct geen beschermingswal. Het is op termijn een drain on resources.

Wanneer is zelf auth bouwen nog wél oké?#

Het is makkelijk om te vervallen in "nooit authcode schrijven". Dat is ook niet juist.

Soms klopt zelf bouwen (of deels) gewoon: interne demo's, vroege prototypes, eenmalige proof of concepts. En als je business knetterfijne, specifieke autorisatie vereist die kant-en-klare platformen écht niet kunnen bieden, is het logisch om dat deel intern te houden, terwijl een externe partij authenticatie, sessies, SSO, MFA en de gebruikersdirectory afvangt.

Let alleen op de POC-glijbaan. We zien steeds hetzelfde patroon: twee developers bouwen zes tot acht maanden aan een prototype met een extern systeem. Het idee is niet slecht. Ze zijn tevreden. Maar het was nooit gemaakt om te schalen.

En een proof of concept maak je het makkelijkst "per ongeluk" permanent. Zes maanden verder is het "de huidige oplossing", twee jaar later "het legacy-systeem", vijf jaar later "onaanraakbare infrastructuur". Het beste moment om thuis-auth te beëindigen, is meestal vóórdat het de basis wordt.

Dus de grens is: het gaat niet om een beetje authcode schrijven. Het gaat om het op je nemen van een generieke infrastructuur-laag en die jarenlang intern houden.

Bouw je eigen randjes. Wees voorzichtig met de identiteitskern. En bouw ongemerkt geen volwaardige CIAM-platform in huis.

Als je het niet bouwt, hoe kies je dan een auth-oplossing?#

Kies je ervoor het niet zelf te schrijven, dan volgt vanzelf de vraag: van wie koop je het, en hoe maak je een keuze?

De meeste volwassen oplossingen bieden sowieso alle features: SSO, MFA, meerdere organisaties, unified login, agent-toegang. Het echte verschil zit meestal niet in de featurelijst.

Wat makkelijker over het hoofd wordt gezien, maar belangrijker is, zijn de onderstaande punten. Het zijn facetten van hetzelfde: klim niet weg uit je eigen code om vervolgens vast te zitten in een systeem waar je niet uit kan stappen.

• Kies voor standaardprotocollen, niet het eigen format van een vendor. OIDC, OAuth en RS256-getekende JWT's zijn gewoon te begrijpen. Je leest claims uit een standaard-token, zonder een vendor-API te hoeven leren.
• Houd een echte uitgang achter de hand. Is het systeem open source en zelf te hosten, kun je altijd overstappen. (Een zelfgehoste versie jarenlang onderhouden heeft natuurlijk z'n eigen verborgen kosten.)
• Laat billing niet je user table volgen. Aantal geregistreerde users of maandactieven is een tabel die alleen groeit, vol mensen die nooit meer inloggen, en dat wordt op schaal een "groeibelasting." Dat is het pricingmodel dat die ledenclub hierboven tot eigenbouw dreef.
• Je data blijft van jou. Je kunt gebruikersdata altijd exporteren. En door gevoelige data aan een gespecialiseerde partij toe te vertrouwen, voorkom je risico’s met privacy-gegevens die je nooit zelf had moeten bewaren.

Full disclosure: Logto is het auth-product dat wij precies tegen deze vier punten gebouwd hebben. Open source, zelf te hosten, maar ook als managed Cloud: geen onderhoud bij Cloud, of volledige controle bij zelf-host, en als je wilt overstappen blijft de deur open.

Sign-in, MFA, SSO en RBAC werken standaard via OIDC, en billing volgt tokens, dus je betaalt wat je gebruikt.

Er zijn ook andere volwassen opties, en auth is nooit een "one right answer." Als je vergelijkt: ik schreef een heel stuk over hoe je een auth-oplossing kiest waar je iets aan hebt.

Conclusie: zie een identity-platform niet aan voor zomaar een feature#

Zelf je auth bouwen is meestal logisch op dag één. Het addertje is dat het later in infrastructuur verandert.

Met elke stap die het bedrijf zet, komt het weer naar voren: enterprises willen SSO, security vraagt MFA, het product wil unified login, meerdere producten moeten koppelen, AI-agents willen resources namens gebruikers. Achter elke mini-feature zitten hele beleidsvragen, en op den duur vreet dat aan de tijd van de engineers die op je core product hoorden te werken.

De rekening komt niet dag één. Hij valt vaak pas jaar later. Tegen die tijd zie je het eindelijk: die loginpagina van toen was al identiteitsinfrastructuur voor de hele levensloop van het product.

Auth is waarschijnlijk niet je core business. Zien je dat snel, dan kun je je tijd, energie en middelen weer steken in het werk dat je echt aan het bouwen bent.

FAQ#

Moet je dan nooit je eigen authenticatiesysteem bouwen?#

Nee. Voor vroege demo's, interne tools, eenmalige validatie, of supergespecificeerde autorisatie die standaard-opties niet aankunnen, kun je zeker zelf bouwen. Waar je voor moet oppassen is dat je ongemerkt een generieke identiteitslaag opbouwt die jarenlang bij je team blijft liggen.

Wat is het verschil tussen authenticatie en autorisatie?#

Authenticatie beantwoordt "wie ben je?" Autorisatie beantwoordt "wat mag je doen?" In een echte SaaS zijn die twee nauwelijks los te koppelen: users, organisaties, rollen, permissies, sessies, tokenclaims en auditlogs grijpen allemaal in elkaar. Dus als je een auth-systeem vervangt, draait het om veel meer dan de loginpagina alleen.

Waarom maakt enterprise SSO zelfbouw-auth complex?#

Omdat je product dan moet koppelen aan het identiteitssysteem van de klant. Klanten gebruiken andere IdP's, protocollen, claimvelden, certificaten en org-mappings. Als de eerste klant werkt, betekent dat niet dat de rest copy-paste is. Het wordt vaak handwerk dat alleen één engineer begrijpt.

We draaien ons eigen systeem al jaren. Kunnen we nog migreren?#

Ja, al is in één keer overstappen meestal niet de route. Migreer in lagen: zet nieuwe sign-ups, logins en enterprise-SSO eerst op het identity platform, en migreer bestaande users bij hun volgende login. Hou een rollback-mogelijkheid en auditlogs bij, zodat de migratie teruggedraaid kan worden als het nodig is.