Tel je wachtwoordrijen eens
Een vraag die het waard is om luidop te stellen op je volgende teamoverleg. Er vertrekt morgen iemand. Noem elk systeem waar die persoon nog op kan inloggen.
Wij probeerden het. De lijst liep op tot meer dan een dozijn: een wagenparkplatform, een rentabiliteitstool, een offertesysteem, een platform voor documentinstroom, statische hosting, een prekalkapplicatie, een tijdsregistratie, een analyseplatform, een schermsysteem, een reservatiesysteem, een toestellenregister, een bedrijfsengine. Elk daarvan had zijn eigen gebruikerstabel. Zijn eigen bcrypt-hashes, zijn eigen wachtwoordmail, zijn eigen sessiecookie, zijn eigen idee van wat een beheerder is.
Twaalf rijen om te verwijderen, in twaalf databanken, in de juiste volgorde, uit het hoofd, op de dag dat iemand vertrekt en iedereen het druk heeft.
Niemand verwijdert twaalf rijen. Mensen verwijderen de vier die ze zich herinneren.
De rest blijft staan en blijft geldig, en de enige reden dat er niets ergs gebeurt, is dat er nog niets ergs gebeurd is.
Hoe je hier belandt zonder het te kiezen
Dit is geen slordigheid. Het is de volstrekt logische uitkomst van een goede gewoonte.
Wij bouwen producten vanuit een gedeelde template. In die template zit authenticatie, want elk product heeft authenticatie nodig, en dat ze er standaard in zit is precies waarom een nieuw product na een week bruikbaar is in plaats van na een maand. Elk nieuw project erft op dag één een werkende login.
Twaalf projecten later heb je twaalf werkende logins. Elke keer was het de juiste lokale beslissing. Samen vormen ze een identiteitssysteem dat niemand ontworpen heeft, met een veiligheidsprofiel dat niemand kan beschrijven.
Elk daarvan was op zich een verstandige keuze. Het kluwen heeft niemand ooit gekozen.
Het tweede symptoom is stiller. Niemand wist nog wat er bestond. Een collega vroeg of we een tool hadden voor iets, en het antwoord was dat we die achttien maanden geleden opgeleverd hadden en dat hij de URL nooit gezien had. Tools die moeilijk te vinden zijn, worden opnieuw gebouwd.
Eén voordeur
DASH is het antwoord waar we op uitkwamen. Het zijn twee dingen in één jas.
Het eerste is een OpenID Connect-provider. Applicaties bewaren geen wachtwoorden meer. Ze sturen door naar DASH, DASH authenticeert, de applicatie krijgt een identiteit terug. Elke aangesloten applicatie is een rij: een slug die meteen haar client id is, een clientgeheim, en haar toegelaten redirect-URI.
Het tweede is een dashboard. Log je in, dan zie je elke tool waar je effectief toegang tot hebt, als tegels, met wat je het meest gebruikt vooraan. Die helft klinkt triviaal naast het identiteitswerk. Ze heeft het dagelijkse gedrag meer veranderd.
Daarbovenop zitten de saaie platformstukken: workspaces, rollen, feature flags, en een superadminweergave waar je ziet welke mensen in welke applicaties bestaan. Iemand uitschrijven is nu één scherm. Toegangsreviews zijn voor het eerst mogelijk, want er is eindelijk een lijst.
Het eerlijke deel
Je eigen identity provider bouwen is een beslissing met een factuur eraan. Dit is de onze, per lijn.
Het is per constructie één punt van falen. Ligt DASH plat, dan logt niemand ergens op in. Vroeger was een storing in één tool een storing in één tool. Nu is het inlogpad gedeeld, en het verdient meer zorg dan om het even welke afzonderlijke applicatie. Bestaande sessies overleven een storing van de provider, wat het verzacht, maar het verdwijnt er niet door.
Een applicatie aansluiten is een procedure van vier stappen over drie repositories. De rij registreren in de databank van de provider. De issuer, client id en redirect-URI toevoegen aan de deployconfiguratie van de applicatie. Het clientgeheim toevoegen aan het versleutelde secretsbestand van die applicatie. De provider herstarten.
Die laatste stap is niet optioneel en niet vanzelfsprekend. Onze provider laadt zijn clientlijst één keer bij het opstarten in een statische array, dus een pas geregistreerde applicatie wordt afgewezen als onbekende client tot de provider herstart. Met één replica is die herstart een venster van tien à twintig seconden waarin niemand ergens kan inloggen.
We weten hoe we dat oplossen. We hebben het niet gedaan, want het gebeurt zelden en een inlogonderbreking om elf uur ‘s avonds is goedkoper dan de code om ze te vermijden. Dat is een legitiem antwoord, maar het is enkel legitiem als je het luidop zegt in plaats van te doen alsof het systeem beter is dan het is.
Fouten zijn stil en misleidend. Een ontbrekend clientgeheim toont zich als een HTTP 500 op de loginroute. Een 404 op diezelfde route betekent iets totaal anders: de OpenID-route zit helemaal niet in die build. Twee oorzaken, twee fouten, één symptoom: “inloggen doet het niet.” Die kennis zit niet betrouwbaar in iemands hoofd, dus staat ze opgeschreven als runbook, met de exacte commando’s en de exacte verwachte statuscodes.
Heeft een procedure vier stappen en kan elk daarvan stil falen, dan moet het een document zijn.
Het onze kostte een namiddag schrijven en heeft zichzelf al meermaals terugverdiend.
Alles wat identiteit betekent is nu van jou. Wachtwoordbeleid. Sessieduur. Resetflows. Tweefactor. Passkeys, wat een project op zich is en geen vinkje. Elk daarvan is nu voor altijd jouw zaak, ook de stukken waar niemand plezier aan beleeft.
Waarom niet gewoon eentje kopen
Terechte vraag, en voor veel bedrijven is het antwoord: doe dat.
Twee dingen duwden ons de andere kant op. Het eerste is wie er inlogt. Onze applicaties zijn multitenant en een groot deel van de accounts zijn geen werknemers. Het zijn medewerkers van klanten, in workspaces, met rollen die iets betekenen binnen één specifiek product. Identiteit die per gebruiker geprijsd wordt, is geprijsd op werknemers. Dat wordt snel ongemakkelijk als de gebruikers de klanten van je klanten zijn.
Het tweede is dat onze applicaties al een workspace- en rollenmodel hadden waar de rest van afhangt, en een externe provider laat je nog altijd identiteiten daarop afbeelden. Dat werk sla je niet over, je doet het alleen tegen andermans abstracties.
Er is nog een kleinere reden die het waard is toe te geven. Het is onze eigen template. Die template één keer OpenID Connect laten spreken betekent dat elk toekomstig product het gratis krijgt, en de meerkost van de dertiende applicatie is één rij en één geheim.
Wat er in de praktijk veranderde
Iemand uitschrijven is één scherm in plaats van een zoektocht. Dat was het doel.
Wat mensen kunnen vinden, wordt gebruikt. Wat één keer in een bericht passeert, verdwijnt stilletjes.
De onsexy winst is echter een andere. Nieuwe interne tools wórden nu gebruikt. Voor DASH betekende iets intern opleveren: een link en een wachtwoord doorsturen en hopen. Nu verschijnt het op ieders dashboard op de dag dat het live gaat. De kloof tussen “we hebben dit gebouwd” en “mensen gebruiken dit” was grotendeels vindbaarheid, en vindbaarheid bleek een probleem van het inlogscherm.
De afweging die we aanvaardden, plat gezegd: we ruilden twaalf kleine risico’s voor één groot risico, en we maakten dat grote zichtbaar. Twaalf vergeten wachtwoordrijen zijn een risico dat niemand ziet en dus niemand beheert. Eén identity provider waar alles van afhangt is een risico met een naam, een runbook, en een duidelijke plek om aandacht aan te besteden.
Dat is niet hetzelfde als veiligheid. Het is de voorwaarde ervoor.