Authenticatie zegt wie iemand is
Een loginflow bevestigt de identiteit van een gebruiker, maar zegt op zichzelf nog niets over wat die persoon in de applicatie mag doen. Dat tweede deel is autorisatie. Door die concepten apart te ontwerpen voorkom je dat 'ingelogd' per ongeluk gelijkstaat aan toegang tot alle data.
Een typische fout is rollen alleen in de interface te gebruiken. Een klant ziet de admin-knop niet, maar kan misschien nog steeds rechtstreeks een endpoint aanroepen. Daarom hoort elke gevoelige lees- of schrijfoperatie server-side te controleren wie de gebruiker is en of die persoon toegang heeft tot het concrete object.
Rollen zijn nuttig, maar objectniveau-permissies blijven nodig
Admin, medewerker en klant zijn bruikbare globale rollen, maar veel regels hangen af van het concrete record. Een klant mag bijvoorbeeld alleen eigen dossiers zien. Daarom moeten queries en serveracties ook controleren of de gebruiker aan het specifieke object gekoppeld is.
Objectniveau-toegang wordt belangrijk zodra meerdere klanten of teams dezelfde applicatie gebruiken. “Medewerker” is dan niet genoeg: de vraag is medewerker van welk bedrijf, project of dossier. Die relaties horen in het datamodel zodat queries dezelfde regels kunnen afdwingen als de rest van het product.
Autoriseer waar de data of actie werkelijk wordt uitgevoerd
Een verborgen knop in de UI is geen beveiliging. Elke gevoelige serverfunctie controleert opnieuw identiteit en rechten voordat ze data leest of wijzigt. De interface kan dezelfde regels gebruiken voor een goede ervaring, maar de backend blijft de echte grens.
Ontwerp rollen daarom vóór de schermen. Schrijf per rol uit welke records zichtbaar zijn, welke acties mogelijk zijn en welke uitzonderingen bestaan. Dat voorkomt dat permissions later als losse if-statements door de UI verspreid raken en maakt security een onderdeel van de architectuur in plaats van een patch achteraf.