Hoe werkt gebruikersbeheer en toegangscontrole in een webapplicatie?
Gebruikersbeheer in een webapplicatie regelt wie er kan inloggen en hoe identiteiten worden geverifieerd. Toegangscontrole bepaalt wat een ingelogde gebruiker mag zien en doen, op basis van rollen of individuele rechten. De twee werken samen: authenticatie bewijst wie je bent, autorisatie bepaalt wat je mag. Een goed ontworpen systeem legt rechten vast op de server, nooit alleen in de interface.
Gebruikersbeheer bepaalt wie er toegang heeft tot een webapplicatie. Toegangscontrole bepaalt wat elke gebruiker mag zien en doen. Beide zijn kritiek voor een veilige applicatie.
Gebruikersbeheer bepaalt wie er toegang heeft tot een webapplicatie. Toegangscontrole bepaalt wat elke gebruiker mag zien en doen. Beide zijn kritiek voor een veilige en beheersbare applicatie, en ze horen al in het ontwerp te zitten, niet pas als de bouw al begonnen is.
Dit artikel legt de concepten uit en geeft inzicht in hoe een goed ontworpen systeem werkt.
Authenticatie: wie ben jij
Authenticatie is het proces waarbij de applicatie bewijst dat jij bent wie je zegt te zijn. De meest bekende vorm is gebruikersnaam en wachtwoord, maar dat is niet de enige optie.
Tweefactorauthenticatie (2FA) voegt een tweede verificatiestap toe, bijvoorbeeld een code via een authenticatie-app. Dat maakt een account significant moeilijker te compromitteren, ook als het wachtwoord uitlekt. Single Sign-On (SSO) laat gebruikers inloggen met een bestaand account, bijvoorbeeld Microsoft of Google, via OAuth2. Dat is comfortabel voor gebruikers en vermindert het beheer van losse accounts.
Welke vorm je kiest hangt af van het risiconiveau van de applicatie. Een interne tool voor een klein team kan volstaan met een eenvoudige login. Een applicatie met gevoelige klantdata of financiële informatie vraagt om 2FA als minimum.
Autorisatie: wat mag jij
Nadat een gebruiker ingelogd is, bepaalt autorisatie wat hij of zij kan doen. Dat werkt via rollen en rechten. Een rol is een profiel dat je toewijst aan een gebruikerstype: Administrator, Manager, Medewerker of Klant, bijvoorbeeld. Elke rol heeft een set rechten: welke pagina’s zijn toegankelijk, welke gegevens zijn zichtbaar, welke acties zijn toegestaan.
Een Administrator mag gebruikers aanmaken en verwijderen. Een Manager ziet rapportages van zijn afdeling maar niet van andere afdelingen. Een Medewerker ziet alleen zijn eigen taken. Een Klant die via een portaal inlogt, ziet alleen zijn eigen facturen en projectstatus. Door rechten te bundelen in rollen beheer je een applicatie met honderd gebruikers net zo eenvoudig als een met tien.
Toegangscontrole op serverniveau
Een veelgemaakte fout is toegangscontrole alleen in de interface regelen. Je verbergt een knop of een menu-item voor gebruikers die er geen toegang toe hebben. Maar als die gebruiker direct een URL intypt of een API-verzoek stuurt, krijgt hij de data toch terug.
Veilige toegangscontrole werkt op serverniveau: de server controleert bij elk verzoek of de ingelogde gebruiker recht heeft op die specifieke actie. Als dat niet zo is, stuurt de server een foutmelding, ongeacht hoe het verzoek is opgebouwd. In moderne applicaties met een database als Supabase wordt dit versterkt met Row Level Security: regels in de database die per rij bepalen welke gebruiker die mag lezen of schrijven. Meer over hoe zo’n applicatie gebouwd wordt lees je op stuurboardbi.nl/diensten/webapplicaties.
Gebruikersbeheer in de praktijk
Naast technische toegangscontrole is er ook de praktische kant: hoe maak je gebruikers aan, hoe pas je rollen aan en hoe verwijder je een account als iemand de organisatie verlaat.
Een goede applicatie heeft een beheerscherm waar een administrator dit zelfstandig kan doen, zonder dat er elke keer een ontwikkelaar aan te pas komt. Dat klinkt vanzelfsprekend, maar wordt in de praktijk vaak vergeten als een “nice to have” die later komt. Zet het in de scope van de eerste versie.
Denk ook aan het offboarding-proces: als een medewerker vertrekt, moet zijn account direct geblokkeerd of verwijderd kunnen worden. Accounts die actief blijven na uitdiensttreding zijn een beveiligingsrisico. Meer over hoe portalen en gebruikersrollen samenkomen lees je in het artikel over klanten- en medewerkerportalen.
Logging en audittrail
Voor sommige toepassingen is het niet alleen belangrijk wie iets mag, maar ook wie iets gedaan heeft. Een audittrail is een log van alle acties in de applicatie: wie heeft welk record gewijzigd, wanneer, en wat was de oude waarde.
Dat is nuttig bij financiële applicaties, zorgomgevingen of toepassingen waarbij compliance een rol speelt. Het stelt je in staat om achteraf te reconstrueren wat er is gebeurd als er een fout of een incident is. Een audittrail implementeer je niet na oplevering, maar ontwerp je mee van het begin.
Onze tip: maak bij de start van het ontwerp een rollenmatrix: een tabel met alle gebruikerstypen als kolommen en alle functies als rijen. Per cel vul je in of die rol die functie mag gebruiken. Dat voorkomt dat je later ontdekt dat rechten inconsistent zijn of dat bepaalde combinaties niet kloppen.
Veelgestelde vragen
Wat is het verschil tussen authenticatie en autorisatie?
Authenticatie bewijst wie je bent: je logt in met een wachtwoord, een code via je telefoon of een externe dienst zoals Google. De applicatie controleert of jij bent wie je zegt te zijn. Autorisatie bepaalt wat je mag doen nadat je bent ingelogd: welke pagina's je kunt openen, welke gegevens je kunt zien en welke acties je kunt uitvoeren. Beide zijn noodzakelijk in elke webapplicatie die meer dan één gebruiker heeft.
Wat zijn rollen en rechten in een webapplicatie?
Een rol is een groep rechten die je toewijst aan een type gebruiker. Typische rollen zijn Administrator, Manager en Medewerker. Een Administrator mag alles beheren, een Manager ziet rapportages van zijn team, een Medewerker ziet alleen zijn eigen gegevens. Rechten zijn de individuele acties die toegestaan zijn, zoals 'factuur aanmaken' of 'gebruiker verwijderen'. Door rechten te bundelen in rollen is beheer overzichtelijker dan elke gebruiker afzonderlijk te configureren.
Hoe zorg ik dat gevoelige data niet zichtbaar is voor verkeerde gebruikers?
De veiligste aanpak is toegangscontrole op serverniveau, niet alleen in de interface. Als een gebruiker niet gemachtigd is om bepaalde data te zien, mag de server die data simpelweg niet terugsturen, ook niet als iemand de URL handmatig intypt of een API-verzoek stuurt. Toegangscontrole die alleen zichtbaarheid in de interface regelt maar de data wel beschikbaar stelt via de API, is onveilig. Row Level Security in een database (zoals Supabase) is een goede aanvulling.
Kan ik Single Sign-On (SSO) integreren in een maatwerk webapplicatie?
Ja, SSO is goed te integreren in een maatwerk webapplicatie. Via protocollen als OAuth2 en OpenID Connect kun je inloggen via Microsoft, Google of een andere identiteitsprovider. Gebruikers hoeven dan geen apart account aan te maken: ze loggen in met hun bestaande bedrijfsaccount. Dat verlaagt de drempel voor gebruik en vermindert het wachtwoordbeheer voor de organisatie. SSO vraagt wel extra technisch werk bij de bouw.