Tweefactorauthenticatie (2FA) toevoegen aan je app

Om tweefactorauthenticatie (2FA) aan je app toe te voegen, laat je gebruikers een authenticatie-app koppelen door een QR-code te scannen. Daarna vraag je na het wachtwoord de zescijferige code die de app toont, en pas daarna maak je op de server een volledige sessie aan, als die code klopt. Geef elke gebruiker bij het aanzetten eenmalige herstelcodes, beperk hoeveel codes iemand kan raden, en vraag het wachtwoord plus een actuele code voordat 2FA kan worden uitgezet. Als je een gehoste authenticatieprovider gebruikt, zet dan zijn ingebouwde multi-factor-optie aan in plaats van zelf code te bouwen.

Deze gids loopt de keuzes door, de exacte stroom, prompts voor een AI-builder, en de fouten die 2FA er aanwezig laten lijken terwijl het niets doet. Als het concept nieuw voor je is, begin dan met wat is tweefactorauthenticatie.

Vooraf: je hebt een werkend inlogsysteem nodig

2FA zit bovenop een bestaande aanmelding. Je hebt er eerst een van deze twee nodig:

Je eigen inlogsysteem, met gebruikers en gehashte wachtwoorden opgeslagen in de database van je app.
Een gehoste authenticatieprovider die gebruikers voor je beheert.

Als je nog geen van beide hebt, begin dan met hoe voeg je inloggen toe aan je app. De rest van deze gids gaat ervan uit dat een wachtwoordstap al werkt.

Kies je tweede factor

Methode	Inspanning voor gebruiker	Beveiliging	Kosten om te draaien	Goede standaard?
Authenticatie-app (TOTP)	Eenmaal een QR-code scannen, bij inloggen een code typen	Goed; te phishen als een nepsite om de code vraagt	Gratis	Ja, voor de meeste apps
Passkey of beveiligingssleutel	Tikken of vingerafdruk gebruiken	Sterkst; bestand tegen phishing	Gratis	Ja, als je gebruikers er gemakkelijk mee omgaan
E-mailcode	Bij inloggen je inbox checken	Alleen zo sterk als het e-mailaccount	Kosten voor het verzenden van e-mail	Alleen als terugvaloptie
Sms-code	Wachten op een sms	Zwakst; SIM-swapping en phishing	Kosten per bericht	Alleen als gebruikers geen app kunnen gebruiken

TOTP staat voor time-based one-time password, de standaard (RFC 6238) die authenticatie-apps gebruiken. Je server en de telefoon van de gebruiker delen een geheim; beide berekenen uit dat geheim en de huidige tijd dezelfde korte code, die meestal elke 30 seconden verandert. Er is geen netwerkverbinding of sms-provider nodig.

Passkeys vervangen of ondersteunen wachtwoorden met een cryptografische sleutel die op het apparaat van de gebruiker wordt bewaard. Ze zijn sterker maar meer werk om zelf te bouwen, dus veel apps beginnen met TOTP en voegen later passkeys toe, of krijgen ze van een authenticatieprovider.

Zelf bouwen of aanzetten?

Aanpak	Voordelen	Nadelen
Multi-factor van een gehoste authenticatieprovider	Minder code; de provider onderhoudt de beveiligingsdetails	Maandelijkse kosten bij schaal; je bent afhankelijk van de opties van de provider
Eigen TOTP met een bibliotheek	Volledige controle; geen kosten per gebruiker	Jij bent verantwoordelijk voor de randgevallen: blokkades, herstel, opslag van geheimen

Controleer de actuele documentatie van je provider voor welke factoren worden ondersteund en op welke abonnementen. Schrijf in beide gevallen nooit zelf de wiskunde voor het genereren van codes; gebruik een algemeen gebruikte bibliotheek.

Bepaal eerst het beleid

Beantwoord deze vragen voordat je prompts schrijft, want ze veranderen het ontwerp:

Wie moet het gebruiken? Optioneel voor iedereen, verplicht voor admins en medewerkers, of verplicht voor iedereen. Verplicht stellen voor iedereen met adminrechten is gebruikelijk. Zie role-based access control.
Hoe vaak moeten gebruikers een code invoeren? Bij elke login, of één keer per apparaat voor 30 dagen ("onthoud dit apparaat").
Welke acties vragen een nieuwe controle? Het wijzigen van het e-mailadres, betaalgegevens of het uitzetten van 2FA zijn goede kandidaten. Dit heet step-up-authenticatie.
Wat is het proces als de telefoon kwijt is? Herstelcodes, plus een handmatige terugvaloptie die je bereid bent uit te voeren.

Stap voor stap: TOTP-2FA op je eigen inlogsysteem

1. Sla de juiste velden op

Elke gebruiker heeft nodig: of 2FA aan staat, het TOTP-geheim (versleuteld opgeslagen, niet als platte tekst), het moment waarop het is aangezet, en een lijst met herstelcodes die gehasht zijn opgeslagen, net als wachtwoorden. Voeg een plek toe om mislukte pogingen te tellen.

2. Inschrijving

De gebruiker opent Instellingen en klikt op Tweefactorauthenticatie aanzetten.
De server genereert een nieuw geheim en geeft het terug als QR-code, plus de tekstversie voor mensen die niet kunnen scannen.
De gebruiker scant de code in een authenticatie-app en typt de huidige code in.
De server controleert de code. Alleen als die klopt, slaat hij het geheim op en markeert 2FA als aan.
De app toont 8 tot 10 herstelcodes één keer en vraagt de gebruiker ze op te slaan.

Stap 4 is belangrijk: 2FA aanzetten voordat de code is bevestigd, sluit iedereen buiten wiens scan is mislukt.

3. Inloggen met een tweede stap

De gebruiker stuurt e-mail en wachtwoord. De server controleert ze.
Als 2FA aan staat, maakt de server geen volledige sessie. Hij maakt een kortdurende status "tweede factor in afwachting".
De app toont het codescherm. De server controleert de code en staat een kleine marge toe voor tijdsverschil van de klok.
Pas dan geeft de server de echte sessie uit.

Elke beschermde route en elk API-eindpunt moet de status "in afwachting" weigeren. Een 2FA-scherm dat alleen pagina's in de browser verbergt, kan worden omzeild door de API rechtstreeks aan te roepen.

4. Limieten en meldingen

Een zescijferige code heeft een miljoen combinaties, en dat is zonder limieten te raden. Begrens het aantal pogingen, blokkeer de tweede stap voor een tijd na herhaalde fouten, en mail de gebruiker wanneer dat gebeurt. Zie rate limiting en e-mail versturen vanuit je app.

5. Herstel en uitzetten

Een herstelcode werkt één keer en wordt daarna verwijderd.
Het uitzetten van 2FA vereist het wachtwoord en een actuele code of herstelcode.
Het opnieuw genereren van herstelcodes maakt de oude set ongeldig.
Mail de gebruiker telkens wanneer 2FA wordt aan- of uitgezet.

Prompts voor je AI-builder

Begin met de kernstroom:

Voeg optionele tweefactorauthenticatie toe met authenticatie-apps (TOTP) aan ons bestaande inloggen met e-mail en wachtwoord. Gebruik een bekende TOTP-bibliotheek, schrijf het algoritme niet zelf. Toon in Instellingen een QR-code en het tekstgeheim, en zet 2FA pas aan nadat de gebruiker een geldige code heeft ingevoerd. Sla het geheim versleuteld op en toon het na de installatie nooit meer. Toon 10 eenmalige herstelcodes één keer en sla ze gehasht op.

Daarna de handhaving, waar gegenereerde code het vaakst tekortschiet:

Handhaaf 2FA op de server. Na een correct wachtwoord krijgen gebruikers met 2FA een kortdurende status "in afwachting", geen volledige sessie. Elke beschermde pagina en API-route moet die status weigeren. Beperk codepogingen tot 5, blokkeer daarna de tweede stap 15 minuten en mail de gebruiker.

Dan beleid:

Verplicht 2FA voor adminaccounts: een admin zonder 2FA wordt naar de installatie gestuurd en komt niet bij het dashboard tot die klaar is. Vereis het wachtwoord en een actuele code om 2FA uit te zetten of het e-mailadres van het account te wijzigen. Mail de gebruiker wanneer 2FA wordt aan- of uitgezet.

Tot slot vraag je de agent uit te leggen wat hij heeft gebouwd:

Geef een lijst van elke route die controleert of een tweede factor is voltooid, waar het TOTP-geheim en de herstelcodes worden opgeslagen, en hoe die zijn beschermd.

Veelgemaakte fouten

Sessie aangemaakt na het wachtwoord. De ernstigste bug. Als de volledige sessie bestaat voordat de code is gecontroleerd, is 2FA alleen decoratie. Test door alleen na de wachtwoordstap een beschermde API aan te roepen.
Geen limiet op pogingen. Onbeperkt raden maakt de code brute-forceable.
Geheimen of herstelcodes in platte tekst. Een databaselek geeft dan ieders tweede factor prijs.
Aanzetten voordat het is geverifieerd. Gebruikers die verkeerd hebben gescand, worden bij de volgende login buitengesloten.
Geen herstelpad. Elke verloren telefoon wordt een supportticket of een verloren klant.
Makkelijk uitzetten. Als een gestolen sessie 2FA kan uitzetten zonder code, is de bescherming weg.
Codes in logs. Zorg dat codes en geheimen nooit in serverlogs of foutmeldingen verschijnen.
Alleen controleren op de inlogpagina. Wachtwoord-resets, "magic link"-aanmeldingen en social login moeten 2FA ook respecteren, anders worden ze een omweg.

Testchecklist

Inschrijving wordt alleen voltooid na een geldige code
Inloggen met een juist wachtwoord maar zonder code geeft geen toegang tot beschermde pagina's of API's
Een verkeerde code wordt geweigerd; herhaalde foute codes activeren de blokkade en een e-mail
Een code van een paar minuten geleden wordt geweigerd
Elke herstelcode werkt precies één keer
Het uitzetten van 2FA vereist het wachtwoord en een actuele code
Wachtwoord-resets omzeilen 2FA niet
Admins zonder 2FA kunnen de adminpagina's niet bereiken (als dat verplicht is)
Geheimen en herstelcodes zijn versleuteld of gehasht in de database
Er verschijnen geen codes of geheimen in logs

Doorloop ook de beveiligingschecklist voor met AI gebouwde apps voor de lancering.

2FA toevoegen in Mythex

Mythex bevat geen ingebouwd inlogsysteem voor de eindgebruikers van je app. 2FA hoort dus bij de authenticatiemethode die je kiest: je eigen e-mail-en-wachtwoordinlog met de database van het project, of een gehoste provider met multi-factor-ondersteuning. Beschrijf wat je wilt in de chat met prompts zoals hierboven. Sleutels van providers gaan in de geheimen van het project (via /secrets, de projectinstellingen of de geheimenkaart die de agent toont), niet in het berichtenveld. Het documentatierecept inloggen toevoegen aan je app heeft een startprompt, en beveiliging voor apps die je bouwt behandelt de gewoontes rond sleutels en rechten. Test na afloop van de agent elk punt op de checklist in Preview voordat je publiceert.

Veelgestelde vragen

Wat is de makkelijkste manier om tweefactorauthenticatie aan een app toe te voegen?

Als je een gehoste authenticatieprovider gebruikt, zet je de ingebouwde multi-factor-optie van die provider aan; dat vraagt meestal de minste code. Als je zelf inlogt, voeg je authenticatiecodes toe via een app (TOTP) met een bekende bibliotheek, plus herstelcodes en een controle op de server.

Moet ik sms-codes gebruiken voor 2FA?

Sms is beter dan geen tweede factor, maar het is de zwakste gangbare optie, omdat sms-berichten via SIM-swapping kunnen worden omgeleid en codes kunnen worden gephisht. Bied een authenticatie-app standaard aan, en passkeys als je gebruikers er klaar voor zijn.

Heb ik een database nodig om 2FA toe te voegen?

Als je zelf inlogt, wel. Het 2FA-geheim van elke gebruiker, of 2FA aan staat, en hun gehashte herstelcodes moeten ergens staan waar je server ze kan controleren. Een gehoste authenticatieprovider slaat dit voor je op.

Wat gebeurt er als een gebruiker zijn telefoon kwijt is?

Die logt in met een van de eenmalige herstelcodes die je hebt getoond toen hij 2FA aanzette, en stelt daarna 2FA opnieuw in op een nieuw apparaat. Zonder herstelcodes heb je een handmatige identiteitscontrole nodig, dus bepaal dat proces vóór de lancering.