Aanmelden lijkt het eenvoudigste scherm van een applicatie en is het lastigste stuk eronder. Het bepaalt wie je klant is, wat hij mag, en wat er gebeurt op de dag dat hij zijn telefoon verliest.
Aan de buitenkant staan je klanten. Die willen niet nog een wachtwoord verzinnen, en elk extra veld op het aanmeldscherm kost er een paar. Een knop waarmee ze de account gebruiken die ze toch al hebben, scheelt afhakers, vergeten wachtwoorden en werk voor wie de helpdesk doet.
Aan de binnenkant staan je medewerkers. Die hebben geen keuze, en daar draait het om iets anders: dat iemand die begint op dag een overal in kan, dat iemand die vertrekt op dag een nergens meer in kan, en dat je dat kan aantonen. Dat is dezelfde technologie met een andere opdracht, en in de praktijk wordt de tweede kant vergeten tot een audit ernaar vraagt.
Daartussen zit de derde categorie, die vaak nergens beschreven staat: de machines. Een koppeling, een script, een assistent die in je applicatie mag. Die melden zich ook aan, vaak met de account van iemand die het ooit heeft opgezet, en dat is meestal het eerste wat stilvalt wanneer die persoon van rol verandert.
Zes stukken tussen een aanmeldscherm en een rechtenmodel dat na drie jaar nog uit te leggen valt.
Google, Apple, Microsoft of Facebook als aanmeldknop, met oauth en OpenID Connect eronder. Aanmelden en een bestaande account koppelen lopen langs dezelfde weg, zodat iemand die eerst een wachtwoord koos later gewoon op de knop kan duwen.
Medewerkers die zich met hun bedrijfsaccount aanmelden bij een eigen applicatie, met de groepen uit de tenant als basis voor wat ze mogen. In en uit dienst gaan dan langs een plek in plaats van langs elk systeem apart.
Een rechtenmodel dat verder gaat dan een rol per gebruiker: een recht per handeling, rollen als bundel, en een scherm waarin je ziet waarom iemand ergens aan mag. Als package, zodat elk project dezelfde regels draait.
Een code uit een authenticator-app, of aanmelden met vingerafdruk of gezicht. Passkeys halen het wachtwoord helemaal weg, wat meteen de hele categorie hergebruikte wachtwoorden uitschakelt.
Laptops en telefoons die zichzelf inrichten bij de eerste aanmelding, met de instellingen, de software en de schijfversleuteling die erbij horen. Een toestel dat kwijtraakt is dan een wisstuk en geen incident.
Machines en assistenten melden zich niet aan met het account van een medewerker die morgen van ploeg verandert, maar met een eigen sleutel of token, met de rechten die erbij horen en niet meer. Intrekken is dan een knop en geen zoektocht.
Vijf dingen die je beter vooraf beslist, want achteraf raak je er niet meer aan zonder aan accounts te komen die al in gebruik zijn.
Twee aanmeldwegen kunnen hetzelfde mailadres teruggeven, en een mailadres kan van eigenaar wisselen. Wie de account daarop koppelt, opent de deur voor wie dat adres later krijgt. De sleutel is het nummer dat de aanbieder meegeeft; het mailadres is een gegeven dat erbij hoort.
Bij de eerste aanmelding komt de naam mee, daarna nooit meer, en het mailadres kan een doorstuuradres zijn dat Apple zelf verzon. Wie die eerste keer niet wegschrijft, heeft een account zonder naam en geen manier om er alsnog aan te raken. Dat is geen bug maar het ontwerp.
Dezelfde persoon meldt zich vandaag met Google aan en volgende maand met een wachtwoord. Dat hoort een account te zijn met twee aanmeldwegen, en niet twee accounts. Dat vraagt een tabel naast de gebruiker, en een moment waarop je vraagt of het inderdaad dezelfde persoon is.
Wie zijn toestel verliest moet ergens terecht, en dat ergens is precies de plek waar een aanvaller het zal proberen. Herstelcodes die een keer werken, een tweede factor die anders werkt dan de eerste, en een procedure die een mens uitvoert: dat is even belangrijk als de verificatie zelf.
Aanmelden geeft je een token, en dat token is vaak ook de sleutel tot wat er daarna nog moet gebeuren: een agenda lezen, een mailbox uitlezen, een bestand ophalen. Dat betekent vernieuwen op tijd, veilig bewaren, en netjes opruimen wanneer iemand de koppeling intrekt.
Een aanmeldknop van een grote aanbieder verlegt het vertrouwen, het verdwijnt niet. Ligt die dienst eruit, dan raakt niemand binnen die enkel die weg heeft. Een tweede weg openhouden is daarom geen luxe maar een voorwaarde, en dat geldt ook voor je eigen medewerkers.
En toegang regelen is geen beveiliging. Het zegt wie er binnen mag, niet wat die persoon daarna kan aanrichten, en niet wat er gebeurt als er iets fout gaat. Dat tweede stuk staat bij continuiteit en herstel.
Of wil je net de andere kant op orde zetten, wie er in je 365-omgeving aan wat kan, dan is dat een gesprek van een uur om te weten waar je staat. Stuur gerust een bericht.
Het verhaal van de aanmeldknop staat uitgewerkt bij aanmelden met Google, Apple en Facebook, en de kant van de werkplek bij Microsoft 365.