Je kunt je eigen authenticatie in een dag bouwen. Dat is de valkuil.
Tientallen B2B-teams vertelden ons hetzelfde verhaal. Het begint als een simpele loginpagina. Daarna komt er echte traffic en verandert het ongemerkt in een identiteit-infrastructuur: het fundament waarop je hele product leunt.
Het leek een feature. Het werd een heel identiteitsmodel.
Elke eigenbouw-authenticatie begint met een paar regels code. Het probleem begint pas na de lancering, wanneer elke kleine beslissing ongemerkt het model vormt waar je hele product op vertrouwt.
Dag één: veertig regels code
E-mail, wachtwoord, hash het, sla het op, vergelijk bij inloggen. Simpel en klaar.
Dag tweehonderd: een stil identiteitsmodel
Wie geldt als gebruiker. Bij welke organisatie hoort hij. Welke sessie is nog betrouwbaar. Hoe trek je toegang weer in.
Jaar vijf: een fundament waar je niet aan kunt komen
Op papier het inlogscherm vervangen betekende in de praktijk het identiteitsfundament herbouwen.
Eigen authenticatie werkt prima – tot het bedrijf verandert
Het laat mensen jarenlang probleemloos inloggen. Maar één bedrijfsverandering maakt van “het is genoeg” ineens “het zit in de weg”. Deze drie triggers komen bij bijna elk groeiend product voorbij.
Enterprise-klanten gaan om SSO vragen
De eerste grote deal komt en inkoop wil SSO via hun eigen Entra of Google Workspace. Dan willen ze zowel SAML als OIDC, want de volgende klant gebruikt weer iets anders. Ieder zijn eigen identiteitsset-up, en bijna niets van het werk kun je hergebruiken.
- Verschillende protocollen, veldmappings en certificaatrotaties per klant
- SSO bouw je niet één keer. Je bouwt het opnieuw voor iedere enterprise-klant
- Het wordt langzaam handwerk dat maar één engineer helemaal snapt
Identiteit die verspreid begon moet nu één geheel worden
Gesplitst per organisatie, per product, vaak via overnames. “Identiteit unificeren” klinkt als een feature; in code betekent het herdefiniëren wie één gebruiker of organisatie is.
- Kan één e-mailadres bij meerdere organisaties horen? Hoe migreer je historische gebruikersnamen?
- Negen producten uit overnames betekent negen authenticatiestacks parallel draaien
- Trek aangepaste toegang in bij alle tegelijk, en audit dit op één plek
AI-agenten en CLI’s gaan gebruikers namens hen vertegenwoordigen
Het zijn niet langer alleen mensen in een browser. Agenten, MCP-servers en command lines claimen allemaal namens een gebruiker te handelen. En jouw authenticatie weet alleen hoe je iemand naar een pagina laat inloggen.
- Voor wie wordt het token uitgegeven, met welk bereik en welke doelgroep?
- Geef slechts één tool of één dataveld toegang, en trek het later weer in
- MCP- en CLI-toegang draait om OAuth, niet om een loginformulier
De werkelijke kosten zitten niet in het bouwen. Maar in het jarenlang onderhouden.
De eerste versie is goedkoop: een paar engineers, een paar weken, klaar. Daarna blijft elk jaar tijd wegstromen die in je eigenlijke kernproduct had moeten gaan.
De rekening is veranderd, niet verdwenen
Je krijgt nooit een factuur met “authenticatie” erop.
Het rust stilletjes op één of twee mensen
De echt kritieke kennis zit in iemands hoofd, niet in de documentatie.
Waar wil je je engineers inzetten?
Geen enkele klant betaalt je meer omdat je je eigen OAuth-server schreef.
Als je het niet zelf bouwt – hoe kies je dan?
De meeste volwassen authenticatiesystemen bieden de functionaliteit al: SSO, MFA, organisaties, unified login, agent access. Het echte verschil: kun je weg? Ga niet van je eigen code over naar een leverancier waar je net zo goed in vastzit.
Standaardprotocollen, geen eigen stack
Een deur waar je echt doorheen kunt
Facturatie volgt niet je gebruikerstabel
Je data zit nooit op slot
Authenticatie is waarschijnlijk niet je core business. Behandel het ook zo.
Logto is open source, zelf te hosten, en ook als beheerde Cloud-dienst te krijgen. Sign-in, MFA, SSO en RBAC werken direct met standaard OIDC. Facturatie volgt tokens, en als je later weg wilt, staat de deur open.