Inloggen toevoegen aan uw app: wachtwoorden, magic links, Google en rollen

Om inloggen aan een app toe te voegen, kiest u een methode — e-mail en wachtwoord, magic links (een eenmalige inloglink die per e-mail wordt verstuurd), of „Inloggen met Google“ — en implementeert u die met een beproefde authenticatiebibliotheek of gehoste dienst in plaats van vanaf nul. Bepaal daarna wat elk type gebruiker mag doen (rollen), en dwing dat af op de server bij elke pagina en elk API-verzoek. Sessies moeten veilige cookies gebruiken, verlopen en correct eindigen bij uitloggen.

Deze gids loopt elke keuze door en de details die een werkende inlog scheiden van een veilige. Voor de concepten erachter, zie wat authenticatie is.

Beslis eerst: hebt u inloggen nodig?

Inloggen voegt wrijving en verantwoordelijkheid toe. U hebt het nodig wanneer:

• Gebruikers privégegevens hebben (hun boekingen, documenten, facturen)
• Gebruikers dingen kunnen wijzigen die anderen zullen zien
• U toegang in rekening brengt
• Verschillende mensen verschillende rechten nodig hebben (eigenaar versus medewerker versus klant)

U hebt het misschien niet nodig voor een marketingsite, een openbare lijst, of een formulier dat u alleen een e-mail stuurt. Een wachtlijst heeft geen accounts nodig; een e-mailveld is genoeg.

De vier gangbare inlogmethoden

Veel apps combineren er twee: Inloggen met Google plus magic links per e-mail is een populaire combinatie die de meeste mensen bereikt zonder wachtwoorden op te slaan.

E-mail en wachtwoord

Als u wachtwoorden aanbiedt, zijn dit de niet-onderhandelbare punten:

• Hash wachtwoorden met een traag wachtwoord-hashalgoritme. De OWASP-richtlijnen voor wachtwoordopslag raden Argon2id aan, met scrypt, bcrypt of PBKDF2 als alternatief. Sla wachtwoorden nooit in platte tekst op of met een snelle algemene hash.
• Wachtwoordresets gebruiken een willekeurige, eenmalig te gebruiken link die verloopt, verstuurd naar het geverifieerde e-mailadres.
• Onthul niet welke e-mails een account hebben. „Als dit e-mailadres bekend is, hebben we een resetlink gestuurd“ is beter dan „Geen account gevonden“.
• Beperk het aantal pogingen om in te loggen en te resetten, om het raden van wachtwoorden te vertragen.
• Sta lange wachtwoorden en wachtwoordmanagers toe; sla regels over die vreemde combinaties van tekens afdwingen.

Magic links en eenmalige codes

Een magic link is een inloglink die per e-mail naar de gebruiker wordt gestuurd. Erop klikken logt hem in. Een eenmalige code is hetzelfde idee, maar wordt ingetypt in plaats van aangeklikt.

• Links en codes verlopen snel en werken maar één keer.
• De link moet de gebruiker inloggen op het apparaat waar hij erop klikt, en het token mag niet in logs of analytics-tools blijven staan.
• U hebt betrouwbare e-mailverzending nodig — zie hoe u e-mails vanuit uw app verstuurt. Test met Gmail en Outlook, en controleer de spammap.

Inloggen met Google (en andere OAuth-aanbieders)

„Inloggen met Google“ gebruikt OAuth en OpenID Connect: Google bevestigt wie de gebruiker is en vertelt uw app zijn e-mail en naam. De instelling gaat, stand september 2026, in de sectie Google Auth Platform van de Google Cloud Console:

1. Maak een project aan of selecteer er een, en vul de pagina Branding in — wat gebruikers op het toestemmingsscherm zien (appnaam, supportadres, logo).
2. Maak op de pagina Clients een client van het type „Webapplicatie“.
3. Voeg uw geautoriseerde JavaScript-oorsprongen en redirect-URI's toe — de exacte adressen waarop uw app draait en waarnaar Google gebruikers terugstuurt na het inloggen.
4. Bewaar de client-ID en het clientgeheim in de geheimen van uw app.

Dingen die vaak misgaan, volgens de OAuth-documentatie van Google:

• redirect_uri_mismatch: het redirect-adres moet exact overeenkomen, inclusief http versus https, hoofdletters en een eventuele slash aan het eind. Voeg er één toe voor uw previewadres en één voor uw live domein.
• HTTPS is verplicht: redirect-URI's moeten HTTPS gebruiken, behalve localhost tijdens ontwikkeling.
• De parameter state moet bij terugkomst worden gecontroleerd om cross-site request forgery te voorkomen. Goede bibliotheken doen dit voor u.

Als u alleen basisgegevens voor inloggen vraagt (naam, e-mail, profiel), zegt Google dat verificatie van de app niet verplicht is. Toegang vragen tot Gmail, Drive of Agenda van gebruikers is iets anders en vereist verificatie.

Zelf bouwen of een aanbieder gebruiken?

Beide eerste opties zijn redelijk. Gehoste aanbieders regelen meer voor u, maar voegen een afhankelijkheid toe en rekenen soms per actieve gebruiker; controleer de actuele prijzen op hun sites. Bibliotheken houden alles in uw database, maar laten u meer zelf correct configureren. Wat u ook kiest, vraag de AI om dat te gebruiken in plaats van inlog- of sessielogica zelf te schrijven.

Rollen en rechten

Inloggen vertelt u wie iemand is. Rechten bepalen wat hij mag doen. Houd het eenvoudig, in het begin:

Regels die belangrijker zijn dan de rolnamen:

• Controleer op de server, elke keer. Een knop verbergen in de pagina stopt niemand die de API rechtstreeks aanroept.
• Beperk op eigenaar. Een lid die „boeking 123“ ophaalt, mag die alleen krijgen als hij van hem is.
• Gebruikers kunnen zichzelf niet promoveren. Negeer rolvelden die vanuit de browser worden verstuurd bij profielupdates.
• Standaard geen toegang. Nieuwe routes moeten inloggen vereisen, tenzij u anders besluit.

Test het met twee accounts: log in als de ene, noteer het ID van een record, log in als de andere en probeer het te openen. Onze beveiligingschecklist bevat de volledige test.

Sessiebeveiliging

Na het inloggen onthoudt de app de gebruiker met een sessie — meestal een cookie. De OWASP-richtlijnen voor sessiebeheer raden aan:

• Sessiecookies ingesteld met Secure (alleen HTTPS), HttpOnly (niet leesbaar voor paginascripts) en SameSite
• Een nieuwe sessie-ID bij het inloggen, en opnieuw wanneer rechten veranderen
• Een time-out bij inactiviteit en een absolute maximale levensduur, op de server afgedwongen
• Uitloggen dat de sessie op de server beëindigt, niet alleen de cookie verwijdert
• Sessies ongeldig gemaakt wanneer een gebruiker zijn wachtwoord wijzigt

Inlogtokens in de local storage van de browser opslaan komt vaak voor in tutorials, maar dan zijn ze bloot voor elk script dat op de pagina draait; veilige cookies zijn meestal de betere standaard voor webapps.

Een prompt die het essentiële dekt

Voeg gebruikersaccounts toe aan deze app. Gebruikers kunnen zich aanmelden en inloggen met e-mail en wachtwoord, of met Google. Gebruik [bibliotheek of dienst] in plaats van zelfgeschreven authenticatiecode. Hash wachtwoorden met Argon2id of bcrypt. Voeg wachtwoordreset per e-mail toe met een eenmalige link die na één uur verloopt. Bewaar sessies in veilige HttpOnly-cookies. Bescherm /dashboard en elke /api-route zodat alleen ingelogde gebruikers ze kunnen gebruiken, en zorg dat gebruikers alleen hun eigen projecten zien. Voeg een rol „admin“ toe die alle gebruikers kan zien; alleen beheerders mogen bij /admin, op de server gecontroleerd.

Test daarna: meld u aan, log uit, log in, reset het wachtwoord, probeer een privé-URL terwijl u uitgelogd bent, en probeer het record van een andere gebruiker.

Veelgemaakte fouten bij met AI gebouwde inlog

• Bescherming alleen in de pagina. De pagina stuurt uitgelogde gebruikers door, maar de API geeft gegevens aan iedereen.
• Geheimen in de browser. OAuth-clientgeheimen en beheersleutels van authenticatiediensten horen op de server.
• Preview- en live-URL door elkaar. Het redirect-URI van Google of de resetlink in de e-mail wijst naar de preview, waardoor inloggen na publiceren breekt.
• Geen e-mailverificatie. Iedereen kan zich aanmelden als anderen@bedrijf.nl. Verifieer het e-mailadres voordat u iets koppelt aan dat adres.
• Alleen het gelukkige pad testen. Probeer verkeerde wachtwoorden, verlopen links en een tweede account.

Inloggen toevoegen in Mythex

Op Mythex is inloggen voor de gebruikers van uw app iets wat u aan uw app toevoegt — het staat los van uw eigen Mythex-account. Mythex biedt geen ingebouwd authenticatieproduct, dus u brengt zelf een authenticatiebibliotheek of -dienst en de bijbehorende sleutels mee:

1. Kies een aanpak — bijvoorbeeld e-mail en wachtwoord die in uw eigen database worden opgeslagen, of de SDK van een gehoste dienst.
2. Als u gebruikers zelf opslaat, heeft de app een database nodig; vraag die in de chat of gebruik /database.
3. Zet de sleutels van de aanbieder in projectgeheimen (/secrets of projectinstellingen).
4. Gebruik een prompt zoals hierboven en test in Preview. Voor Inloggen met Google voegt u redirect-URI's toe voor zowel uw previewadres als uw gepubliceerde adres.

Zie Inloggen toevoegen aan uw app in de documentatie. Bouwt u een betaald product, dan behandelt hoe u een SaaS-MVP bouwt accounts en facturatie samen.

Veelgestelde vragen