Hoe regel je inloggen en gebruikers veilig?

Er spelen twee vragen, en ze worden vaak door elkaar gehaald:

• Authenticatie: wie ben je? Dat is het inloggen zelf, met e-mail en wachtwoord, een link per mail of een Google-account.
• Autorisatie: wat mag je? Dat bepaalt welke gegevens en functies iemand na het inloggen mag gebruiken.

Een voorbeeld uit het dagelijks leven: een toegangspas laat je het kantoorgebouw in (authenticatie), maar bepaalt niet in welke kamers je mag komen (autorisatie). Een goed gebouw controleert bij elke deur opnieuw.

Veel gevibecodede apps hebben het eerste goed geregeld en het tweede niet. Iedereen moet inloggen, maar wie eenmaal binnen is, kan via een kleine omweg bij alles. Autorisatie hoort in de database (bij Supabase met Row Level Security (opent in een nieuw tabblad)¹) of in code op de server. Hoe dat werkt, lees je in Is mijn app veilig?

Gebruik een dienst. Wachtwoorden veilig opslaan, inlogpogingen beperken, sessies laten verlopen en wachtwoord-herstel veilig maken is vakwerk. Een inlogdienst heeft dat al opgelost.

Opties die veel gebruikt worden:

• De ingebouwde dienst van je tool. Lovable en Replit hebben bijvoorbeeld inloggen in hun eigen back-end.
• Supabase Auth, als je Supabase als database gebruikt.
• Een losse dienst zoals Clerk, Auth0 of Firebase Authentication.

Wat je in elk geval niet wilt: een tabel "gebruikers" met een kolom "wachtwoord" waarin de wachtwoorden leesbaar staan (opent in een nieuw tabblad)². Staat dat in je project, dan moet het over naar een inlogdienst. Dat zetten we voor je om.

Let bij de keuze ook op waar de dienst je gebruikersgegevens bewaart. E-mailadressen en namen zijn persoonsgegevens. Zie Waar staat je data?

• E-mail en wachtwoord. Bekend voor iedereen. Wachtwoord vergeten moet dan wel goed geregeld zijn.
• Een inloglink per mail (magic link). Geen wachtwoord om te onthouden. Werkt alleen zo goed als de bezorging van je mail.
• Inloggen met Google, Apple of Microsoft. Snel voor de gebruiker, maar vraagt extra instellingen bij die partijen.

Eén of twee manieren is een goed begin. Elke extra manier moet ingesteld, getest en onderhouden worden.

Verstuurt je app mail, zoals een inloglink of een bevestiging, dan moet die ook aankomen en niet in de spam belanden. Mail vanaf je eigen domein vraagt een paar instellingen; zie Hosting en een eigen domein.

Een werkend inlogscherm is het begin. Deze onderdelen horen er ook bij:

• E-mailadres bevestigen. Zo weet je dat het adres echt van de gebruiker is.
• Wachtwoord vergeten. De link moet werken, na een tijd verlopen en maar één keer bruikbaar zijn (opent in een nieuw tabblad)³.
• Uitloggen. Ook op een gedeelde computer moet uitloggen echt uitloggen.
• Account verwijderen. Onder de AVG mogen mensen vragen om hun gegevens te laten wissen (opent in een nieuw tabblad)⁴. Dat moet kunnen, liefst zonder handwerk in de database. Zie Privacy en de AVG.
• Rollen. Heb je beheerders en gewone gebruikers? Dan hoort de rol op de server vast te liggen, niet in de browser. Een gebruiker mag zichzelf nooit beheerder kunnen maken door iets in zijn profiel te wijzigen.
• Uitnodigen en teams. Kunnen gebruikers anderen toevoegen? Dan moet ook geregeld zijn wat er gebeurt als iemand het team verlaat.

Dat zie je niet als je je app zelf gebruikt. Het blijkt pas als iemand met een tweede account probeert bij de gegevens van een ander te komen: via een lijst, via het adres van een pagina, of door iets te wijzigen of te verwijderen. Lukt dat, dan is de autorisatie niet goed (opent in een nieuw tabblad)⁵.

Eén keer controleren is niet genoeg. Een AI die een nieuwe functie bouwt, kan een bestaande regel ongemerkt ruimer maken. Daarom hoort de test na elke grote wijziging opnieuw. Wij doen die test voor je, met meerdere accounts en ook uitgelogd, en zetten dicht wat openstaat. Meer over testen lees je in Testen voordat je live gaat.