Wachtwoordloos inloggen met magische links: UX- en beveiligingschecklist

Wat een magic link-aanmelding is, en wat er mis kan gaan

Een magic link is een eenmalige aanmeldlink die naar je e-mail wordt gestuurd. In plaats van een wachtwoord in te typen open je de e-mail, tik je op de link en je bent ingelogd.

Dit kan goed werken wanneer mensen een hekel hebben aan wachtwoorden, ze vaak vergeten of alleen af en toe inloggen. Het kan ook hergebruik van wachtwoorden verminderen, omdat er geen wachtwoord is om opnieuw te gebruiken. Maar het haalt de noodzaak voor beveiliging niet weg. Het verplaatst simpelweg de belangrijkste “sleutel” naar je e-mailinbox.

Dat is de afweging: wachtwoordloos inloggen met magische links is slechts zo veilig als het e-mailaccount van de gebruiker en hun vermogen om toegang privé te houden. Als iemand je e-mail kan lezen, kan die persoon zich vaak als jou aanmelden.

Hier zijn de meest voorkomende manieren waarop magic links in de praktijk misgaan:

• Toegang tot de inbox wordt gestolen (phishing op e-mailwachtwoord, SIM-swap voor e-mailherstel, malware, of een gedeelde computer die ingelogd is achtergelaten).
• De link wordt doorgestuurd (opzettelijk of per ongeluk) en de verkeerde persoon gebruikt hem.
• De gebruiker opent de e-mail op één apparaat maar wil de sessie op een ander apparaat, en raakt in de war wanneer de app op de “verkeerde” plek opent.
• Een gedeeld apparaat logt in en blijft ingelogd, zodat de volgende persoon toegang heeft.
• Het e-mailadres is verkeerd getypt en een aanmeldlink gaat naar iemand anders.

Een klein voorbeeld: iemand vraagt een link aan op een werk-laptop en checkt vervolgens e-mail op een persoonlijke telefoon. Ze tikken op de link, de telefoon logt hen in en de laptop toont nog steeds het aanmeldscherm. Als je flow niet uitlegt wat er gebeurde, volgen supporttickets.

Als je dit bouwt in een product gemaakt met AppMaster, behandel de e-mailstap als een gevoelige actie, niet alleen als een gebruiksgemakfunctie. Duidelijke communicatie, kortlevende links en eenvoudige sessiecontroles maken de ervaring veilig.

Is wachtwoordloze e-mailaanmelding geschikt voor jouw product?

Wachtwoordloos inloggen met magische links werkt het beste wanneer het doel snelle toegang met minimale frictie is, niet maximale bescherming. Het is een goede keuze voor producten waarbij mensen af en toe inloggen en wachtwoorden vergeten, en waar een e-mailinbox al het “thuis” van de gebruiker is.

Een eenvoudige manier om te beslissen is: als iemand in het verkeerde account terechtkomt, wat is de ergste realistische schade? Als het antwoord “irritant, maar te herstellen” is, kunnen magic links een goed standaardoptie zijn.

Wat goed past zijn vaak:

• Apps met laag tot gemiddeld risico (interne tools, adminpanelen voor kleine teams, klantenportalen met beperkte permissies)
• Producten met weiniggebruikers die een hekel hebben aan wachtwoordresets
• “Snel erin” ervaringen zoals support, onboarding of goedkeuringen
• Vroege-stage producten die minder supporttickets willen

Wees voorzichtig of vermijd magic links als enige aanmeldmethode wanneer:

• Accounts veel waarde hebben (geldverkeer, grote saldo’s, onomkeerbare acties)
• Je gereguleerde of gevoelige gegevens opslaat (gezondheid, juridische of gedetailleerde financiële gegevens)
• Gebruikers vaak e-mailinboxes delen (gedeelde mailboxen, receptie-accounts)
• Je doelgroep waarschijnlijk doelwit is (directieleden, admins, hooggeprivilegieerde rollen)

Als je product gevoelige momenten heeft in plaats van gevoelige accounts, gebruik dan e-mailaanmelding voor toegang en voeg een tweede factor of stap-op verificatie toe voor risicovolle acties. Bijvoorbeeld: vraag extra bevestiging bij het wijzigen van uitbetalingsgegevens, het exporteren van data of het toevoegen van een nieuwe admin.

Bepaal ook wat e-mail mag doen. “Alleen inloggen”-magische links zijn veiliger en makkelijker te begrijpen. “Inloggen + accountherstel” is handig, maar het betekent dat iedereen met toegang tot de e-mail het account kan overnemen. Als je het e-mailadres kunt wijzigen, behandel dat dan als een risicovolle actie.

Als je een app bouwt in een no-code platform zoals AppMaster, blijft deze beslissing belangrijk: de UI kan eenvoudig zijn, maar je beleid rond gevoelige acties en herstel moet vanaf dag één expliciet zijn.

De basis flow van een magic link (en de beslissingen erin)

Magic links voelen eenvoudig voor gebruikers, maar er liggen veel kleine keuzes onder de motorkap. Een nette flow houdt mensen in beweging en vermindert supporttickets.

De flow die gebruikers zien

De meeste producten volgen hetzelfde pad: de gebruiker voert een e-mail in, ontvangt een bericht, tikt op de link en komt ingelogd aan.

Een veelvoorkomende verbetering is een laatste bevestigingsstap nadat de link opent. In plaats van direct in te loggen, laat je een kort scherm zien zoals “Bevestig aanmelding bij Acme” met één knop. Dit helpt wanneer iemand de link op het verkeerde apparaat tikt of de e-mail door een preview-tool wordt geopend.

Op mobiel moet je beslissen wat “tik op de link” betekent. Als je een native app hebt, is de beste ervaring meestal: tik link -> open de app -> voltooi aanmelding. Als de app niet is geïnstalleerd, val dan terug op mobiele web en bied later een optie “Open de app”.

Beslissingen die je moet maken

Besluit deze regels voordat je wachtwoordloos inloggen met magische links bouwt, zodat de ervaring voorspelbaar is:

• Waar de link opent: in-app browser, systeembrowser of direct in de native app (deep link).
• Of aanmelden automatisch gebeurt of een laatste bevestigingsscherm vereist.
• Wat je doet als de gebruiker al is aangemeld wanneer ze op de link tikken.
• Wat er gebeurt als het e-mailadres tijdens de flow wordt gewijzigd of de gebruiker een ander e-mailadres invult bij een volgende poging.
• Wat “succes” betekent: terug naar de laatste pagina, een standaardhome-scherm of de pagina die de aanmelding activeerde.

Al aangemeld zijn is makkelijk over het hoofd te zien. Als een ingelogde gebruiker een nieuwe magic link tikt, kun je (a) hen in hetzelfde account houden en “Je bent al aangemeld” tonen, of (b) het als accountwissel behandelen en om bevestiging vragen. Voor apps gebouwd in AppMaster (zoals klantenportalen of interne tools) is optie (a) meestal veiliger, tenzij accountwissel een echte functie is.

Vervaltijden: kort genoeg om veilig te zijn, lang genoeg om te werken

Een magic link is alleen “wachtwoordloos” als het moeiteloos voelt. Verval is het deel dat stilletjes die belofte kan breken. Te kort en mensen treffen verlopen links in hun inbox en geven op. Te lang en een doorgestuurde of blootgestelde e-mail wordt een groter risico.

Een praktisch startpunt voor wachtwoordloos inloggen met magische links is een vervalvenster tussen 10 en 30 minuten. Kortere vensters (3–10 minuten) passen bij acties met hoger risico, zoals inloggen op een admingebied of het goedkeuren van een betaling. Langere vensters (30–60 minuten) kunnen werken voor laag-risico apps, maar alleen als je sterke sessiecontroles en goed apparaatbeheer hebt.

Maak de vervaltijd duidelijk in de e-mail en op het “Controleer je e-mail”-scherm. Verberg het niet in kleine tekst. Gebruik eenvoudige formuleringen zoals “Deze link verloopt over 15 minuten.” Als je kunt, toon een aftelklok op het wacht-scherm, maar vertrouw niet op de klok van de gebruiker voor nauwkeurigheid.

E-mailvertragingen en klokverschillen komen vaak voor. Sommige providers houden berichten een paar minuten vast en sommige gebruikers openen de e-mail op een ander apparaat dan waarop ze het hebben aangevraagd. Een paar regels helpen verwarring te vermijden:

• Hanteer verval op basis van je servertijd, niet de tijd van de gebruiker.
• Als een link bijna verloopt, toon dan een duidelijk bericht zoals “Link verlopen. Vraag een nieuwe aan.”
• Als de link nog geldig is maar al gebruikt, zeg dat direct (en bied een snelle volgende stap).

Als een link is verlopen, is de beste ervaring een een-klik-herschikking vanaf de landingspagina. Houd het veilig: sta alleen opnieuw verzenden toe na een korte cooldown en vermijd het onthullen of een e-mail in je systeem bestaat. De pagina kan zeggen “Als dit e-mailadres geregistreerd is, sturen we een nieuwe link.”

Een klein detail dat supporttickets vermindert: toon het exacte e-mailadres waar de link naartoe is gestuurd (gedeeltelijk gemaskeerd) op het wacht-scherm, plus een optie “E-mailadres wijzigen”. Als je de flow bouwt in een no-code tool zoals AppMaster, is dit meestal slechts een paar UI-staten, maar het voorkomt veel “Ik heb de e-mail nooit gekregen”-verwarring.

Eenmalig gebruik en hergebruikregels (de delen die gebruikers echt raken)

Voor de meeste producten is de standaard: magic links éénmalig gebruiken. Dat beschermt gebruikers tegen veelvoorkomende ongelukken zoals e-maildoorgifte, gedeelde inboxen of iemand die een oud bericht weken later heropent. Het maakt support ook eenvoudiger: als een link is gebruikt, is hij klaar.

Het belangrijkste is beslissen wat “gebruikt” in de echte wereld betekent. Mensen klikken twee keer, openen op het verkeerde apparaat of tikken in een e-mailpreview. Je regels moeten veilig zijn, maar ook eerlijk aanvoelen.

Wat zou er moeten gebeuren als dezelfde link twee keer wordt geopend?

Een goed uitgangspunt: de eerste succesvolle login consumeert het token en een latere open toont een duidelijk bericht zoals “Deze link is al gebruikt. Vraag een nieuwe aan.” Vermijd vage fouten. Als je frustratie wilt verminderen, kun je een kleine veiligheidsvenster bieden voordat je de link als gebruikt markeert; bijvoorbeeld: markeer pas als gebruikt nadat de sessie is aangemaakt.

Hier zijn gebruikersvriendelijke patronen die veilig blijven:

• Als de link opnieuw op hetzelfde apparaat wordt geopend en de gebruiker al is ingelogd, breng ze naar de app (en toon niets).
• Als de link opnieuw wordt geopend maar er geen actieve sessie bestaat, toon “Gebruikt of verlopen” plus een knop om een nieuwe link te sturen.
• Als de link op een ander apparaat wordt geopend nadat hij al is gebruikt, behandel hem als ongeldig en vraag om een nieuwe link.

Als gebruikers meerdere links aanvragen, vervallen oudere dan?

Bepaal dit vooraf en wees consistent. De veiligste standaard is: elk nieuw verzoek maakt alle voorgaande uitstaande links ongeldig. Dit beperkt schade als iemand later toegang tot een inbox krijgt.

Als je meerdere links tegelijk geldig houdt, heb je sterkere beschermingen nodig (korte vervaltijd, strikte eenmalige gebruiksregels en duidelijke apparaat-/sessiecontroles). Anders kunnen wachtwoordloze magic links ongemerkt veranderen in langlevende toegangssleutels in e-mail.

Vermijd herbruikbare links die keer op keer werken. Zelfs als het handig lijkt, leert het gebruikers e-mail als permanente sleutel te zien en maakt het accountovernames veel moeilijker te beheersen.

Als je je auth-flow in een no-code tool zoals AppMaster bouwt, schrijf deze regels op als duidelijke toestanden (geldig, gebruikt, verlopen, vervangen) zodat je UI-berichten overeenkomen met wat je backend echt afdwingt.

UX-details die verwarring en supporttickets verminderen

De meeste supporttickets rondom magic links zijn geen beveiligingsfouten. Het zijn “Ik heb de e-mail niet gekregen”, “Ik klikte en er gebeurde niets” of “Is dit phishing?”. Goede UX voorkomt alle drie.

Na het indienen van het e-mailadres, toon een toegewijd “Controleer je e-mail”-scherm in plaats van een klein toast-bericht. Maak het rustig en specifiek: vertel naar welk adres je hebt gestuurd, wat de volgende stap is en wat te proberen als het niet aankomt.

Een sterk check-e-mail scherm bevat meestal:

• Het exacte gebruikte e-mailadres, met een duidelijke “E-mailadres wijzigen” optie
• Een resend-knop met een korte aftelling (zodat gebruikers niet blijven klikken)
• Een opmerking over typische levertijd (bijvoorbeeld “Komt meestal binnen 1 minuut aan”)
• Een vriendelijke herinnering om spam, promoties en bedrijfsfilters te controleren
• Een korte regel over veiligheid: “Stuur deze link niet door”

Vertrouwen win je in de e-mail zelf. Gebruik een consistente afzendernaam en onderwerp, en houd de inhoud voorspelbaar. Voeg één of twee details toe die gebruikers zekerheid geven, zoals “Aangevraagd vanuit Chrome op Windows” of “Aangevraagd om 15:42”. Vermijd angstaanjagende tekst. Simpel is beter: “Deze link logt je in. Als jij dit niet hebt aangevraagd, kun je deze e-mail negeren.”

Plan ook voor het meest voorkomende falen: vertraagde of gefilterde e-mail. Je UI moet niet vastlopen. Als de link even kan duren, vertel gebruikers wat ze kunnen doen en bied een vriendelijke fallback.

Een praktische fallback is een korte eenmalige code in dezelfde e-mail als de link. Dan kan het check-e-mail scherm “Voer in plaats daarvan een code in” aanbieden voor gevallen waarin de link op het verkeerde apparaat opent of geblokkeerd wordt door een e-mailscanner.

Een klein maar belangrijk detail: als een gebruiker op een oude of al gebruikte link klikt, toon een behulpzaam bericht en één duidelijke volgende stap zoals “Stuur me een nieuwe link”, niet een generieke foutmelding.

Beveiligingsbasisregels achter de schermen (geen zware crypto-taal)

Een magic link is alleen zo veilig als het token erachter. Behandel dat token als een tijdelijke sleutel voor het account: het moet moeilijk te raden zijn, kortlevend en alleen bruikbaar op de manier die je bedoelde.

Begin met onvoorspelbaarheid. Genereer lange, willekeurige tokens (niet gebaseerd op e-mail, tijd of incrementele ID’s). Sla zo min mogelijk op. Een gangbaar patroon is om een gehashte versie van het token op te slaan (zodat als je database lekt, de ruwe link niet hergebruikt kan worden) plus net genoeg metadata om te valideren.

Het binden van het token aan context kan doorgifte voorkomen. Je wilt niet altijd strikte binding (mensen wisselen apparaten), maar je kunt lichte controles toevoegen om duidelijk misbruik te vangen. Voorbeelden: koppel het token aan het e-mailadres waarvoor het is aangevraagd en optioneel aan een grove fingerprint zoals de user-agent familie of het eerste IP-bereik. Als de context niet overeenkomt, kun je om een nieuwe link vragen in plaats van hard blokkeren.

Rate limiting is belangrijker dan fancy wiskunde. Zonder beperkingen kunnen aanvallers je aanmeldformulier spammen, gebruikers irriteren en onderzoeken of e-mails bestaan.

• Beperk verzoeken per e-mail en per IP (inclusief resends)
• Voeg een korte cooldown toe tussen e-mails (bijvoorbeeld 30–60 seconden)
• Toon hetzelfde bericht of het e-mailadres bestaat of niet
• Waarschuw bij pieken (veel e-mails naar veel adressen)

Log ten slotte wat je echt nodig hebt wanneer een gebruiker zegt “Ik heb dit niet gedaan.” Leg gebeurtenissen vast zoals link aangevraagd, e-mail verzonden, link geopend, token geaccepteerd/mislukt (en waarom) en sessie aangemaakt. Voeg tijdstempel, IP en user-agent toe. In een tool gebouwd met AppMaster kunnen deze gebeurtenissen worden opgenomen in je login businessprocessen, zodat support en security een duidelijk spoor hebben zonder in serverinternals te graaien.

Apparaat- en sessiebeheer dat gebruikers begrijpen

Magic links vervangen wachtwoorden, maar gebruikers denken nog steeds in apparaten: “Ik ben ingelogd op mijn telefoon” of “Ik gebruikte een gedeelde laptop.” Als je ze geen eenvoudige manier geeft om sessies te zien en te beëindigen, stijgt het aantal supporttickets snel.

Begin met één beslissing: hoeveel actieve sessies mag één account tegelijkertijd hebben? Voor de meeste consumentenproducten zijn meerdere sessies prima (telefoon + laptop). Voor gevoelige tools (adminpanelen, financiën, interne operatie) kun je het limitteren of om een nieuwe magic link vragen wanneer een nieuw apparaat verschijnt.

Een klein “Apparaten” of “Actieve sessies” pagina maakt dit makkelijk te begrijpen. Houd het simpel en licht imperfect in plaats van over-precies. Een goede rij bevat meestal:

• Apparaatstnaam (of browser en OS als je het model niet kunt detecteren)
• Grove locatie (stad of regio, geen volledig adres)
• Laatst actief tijd
• Voor het eerst gezien tijd
• Een korte label zoals “Dit apparaat” voor de huidige sessie

Geef daarna twee duidelijke acties. “Uitloggen” moet alleen die sessie beëindigen. “Uitloggen van alle apparaten” moet alles beëindigen, inclusief het huidige apparaat, en overal nieuwe magic links afdwingen.

Definieer tussen die acties wat er gebeurt wanneer een apparaat kwijtraakt of gedeeld wordt. De veiligste standaard is: uitloggen maakt alle bestaande sessies ongeldig en annuleert ongebruikte magic links die al zijn verzonden. Gebruikers hoeven de details niet; ze willen de garantie dat de oude toegang weg is.

Hier is een eenvoudig gedragssetje dat gebruikers zelden verrassend vinden:

• Nieuwe magic link-aanmelding creëert een nieuwe sessie
• Elke sessie heeft een idle timeout (bijvoorbeeld dagen) en een harde maximale levensduur (bijvoorbeeld weken)
• E-mail wijzigen triggert “uitloggen van alle apparaten”
• “Uitloggen van alle apparaten” annuleert ook hangende sign-in links

Als je dit in AppMaster bouwt, kun je sessies modelleren in de Data Designer, ze tonen in een basis web/mobiele UI en één-knop-acties toevoegen in een Business Process. Gebruikers krijgen zo een vertrouwde “actieve sessies” weergave zonder dat het een beveiligingsboekwerk wordt.

Dreigingen en randgevallen: doorsturen, gedeelde e-mails en typefouten

Magic links voelen simpel, maar e-mail is rommelig. Mensen sturen berichten door, delen inboxen en typen adressen verkeerd. Als je alleen voor het perfecte geval ontwerpt, eindig je met verwarrende lockouts en moeilijk te behandelen supportcases.

Doorsturen is de grootste verrassing. Een wachtwoordloze login met magische links moet ervan uitgaan dat de link door iemand anders geopend kan worden, op een ander apparaat, minuten of uren later. De veiligste basis is eenmalig gebruik plus een duidelijk “deze link is al gebruikt” bericht, met een knop om een nieuw verzoek te doen. Als je extra bescherming wilt, toon dan een lichte bevestigingsstap na het klikken wanneer het apparaat nieuw is (bijvoorbeeld “Was jij dit?” plus een snelle annuleeroptie die de sessie intrekt).

Gedeelde inboxen vragen om een productbeslissing, geen technische pleister. Als meerdere mensen legitiem dezelfde e-mail lezen (zoals support@ of sales@), worden magic links standaard gedeelde toegang. Overweeg extra stappen voor “team” accounts (zoals een uitnodiging naar een persoonlijk e-mailadres) of maak duidelijk in de UI dat e-mailtoegang gelijkstaat aan accounttoegang.

Typfouten creëren “spookaccounts” en onhandige privacyproblemen. Vermijd het stilletjes aanmaken van nieuwe accounts bij de eerste aanmelding, tenzij je product dat echt nodig heeft. Een veiligere aanpak is intentie in de app bevestigen voordat je onboardt en houd de e-mailrespons neutraal (dezelfde boodschap of het account bestaat of niet).

Aliassen zijn ook relevant. Bepaal hoe je omgaat met plus-addressing (naam+tag@) en provideraliassen:

• Behandel e-mails als exacte strings (eenvoudiger, minder verrassingen)
• Of normaliseer veelvoorkomende patronen (minder dubbele accounts, maar risico dat je gebruikers samenvoegt die dat niet verwachten)

Support is waar het snel mis kan gaan. Vraag gebruikers niet om e-mails door te sturen, tokens te plakken of screenshots van links te delen. Bied in plaats daarvan eenvoudige in-product acties zoals “stuur een nieuwe link”, “log andere apparaten uit” en “meld dat dit niet ik was”, zodat support kan helpen zonder gevoelige data aan te raken.

Snelle checklist voordat je lanceert

Voordat je wachtwoordloos inloggen met magische links lanceert, beslis wat je wilt dat er gebeurt in de rommelige echte wereld: trage e-maillevering, mensen die twee keer klikken en gebruikers die tussen telefoon en laptop schakelen.

Begin met de regels die risico en supportbelasting beheersen. Als je deze verkeerd zet, kan de UI je niet redden.

• Stel een duidelijk vervalvenster in (vaak 10–20 minuten) en toon het in de e-mail en op het “Controleer je e-mail”-scherm.
• Maak links standaard eenmalig gebruik en definieer wat “gebruikt” betekent (na klik, na succesvolle sessiecreatie of na eerste open).
• Voeg resend-limieten en pacing toe (bijvoorbeeld een korte cooldown), plus een vriendelijk bericht dat uitlegt waarom ze niet kunnen blijven spammen op “stuur opnieuw”.
• Beperk actieve sessies per gebruiker waar dat zinvol is en beslis wat er gebeurt als het limiet is bereikt (behoud nieuwst, behoud oudst of vraag).
• Hanteer meerdere klikken en oude links voorspelbaar: als een link verlopen of al gebruikt is, toon een simpele pagina met één primaire actie (“Stuur een nieuwe link”).

Controleer daarna de onderdelen die gebruikers echt zien. De meeste klachten komen door onduidelijke e-mails en verwarrend mobiel gedrag.

• E-mailinhoud: herkenbare afzendernaam, duidelijke onderwerpregel, eenvoudige taal en een korte “Niet aangevraagd?” regel die uitlegt wat te doen.
• Mobiel gedrag: bevestig wat er gebeurt als de gebruiker de e-mail op één apparaat opent maar op een ander wil inloggen, en of je deep links naar je app ondersteunt.
• Meerdere klikken: als een gebruiker twee keer tikt, vermijd enge fouten; zeg dat ze al zijn ingelogd of dat de link niet meer geldig is.
• Apparaatbeheer: bied een eenvoudige apparatenlijst, een “log uit op dit apparaat”-optie en basis auditgegevens (tijd, apparaat, locatie indien beschikbaar).
• Herstel: heb een plan voor “Ik heb geen toegang tot mijn e-mail” (supportflow, alternatieve verificatie of een veilig proces voor accountwijziging).

Als je dit in een tool zoals AppMaster bouwt, koppel elk checklistitem aan een concreet scherm en een bedrijfsregel in je logica, zodat gedrag consistent blijft tussen web en mobiel.

Een realistisch voorbeeld: nieuw apparaat-aanmelding, verlopen link en opruimen

Maya werkt bij support. Op maandagochtend opent ze het klantenportaal op een nieuwe laptop. Ze voert haar werk-e-mail in en tikt op “Stuur me een aanmeldlink”. De e-mail komt binnen met een magic link die over 10 minuten verloopt.

Ze klikt erop, de browser opent en ze komt in het portaal. Achter de schermen wordt de link eenmaal geaccepteerd en daarna als gebruikt gemarkeerd. Het portaal maakt een nieuwe sessie aan voor “Maya - Laptop Chrome” en houdt haar ingelogd voor 14 dagen tenzij ze uitlogt.

Later die dag probeert Maya in te loggen vanaf haar telefoon. Ze gebruikt de oude e-mail uit de ochtend en tikt opnieuw op dezelfde link. De app toont een duidelijk bericht: “Die link is al gebruikt. Vraag een nieuwe aan.” Ze vraagt nog een link aan, maar wordt afgeleid. Vijfentwintig minuten later tikt ze erop en ziet ze: “Deze link is verlopen. Stuur een nieuwe.” Ze vraagt opnieuw en tikt direct; de phonesessie wordt aangemaakt als “Maya - iPhone Safari”.

Op vrijdag helpt Maya een collega op een gedeelde kantoor-laptop. Ze logt in, voltooit de taak en gaat dan naar “Apparaten” en tikt op “Uitloggen op dit apparaat”. Voor ze vertrekt verwijdert ze ook de sessie van de gedeelde laptop uit haar account zodat die niet opnieuw gebruikt kan worden.

Hier zijn de simpele regels die de app volgde:

• Links verlopen snel (minuten), maar sessies kunnen langer duren (dagen)
• Elke link werkt één keer; gebruikte of verlopen links kunnen niet opnieuw gebruikt worden
• Iedere aanmelding creëert een benoemde apparaat-sessie die de gebruiker kan bekijken
• Gebruikers kunnen uitloggen van één apparaat of alle sessies intrekken indien nodig

Om deze flow in AppMaster te bouwen, begin met de authenticatiemodule en schakel e-mailaanmelding in. Sla sessies op in je database (gebruiker, apparaatsnaam, aanmaaktijd, laatst gebruikt tijd). Gebruik de e-mailmodule om de aanmeld-e-mail te sturen en een kort businessproces om tokenstatus te valideren (ongebruikt, niet verlopen), en maak of trek sessies in. Als je wachtwoordloos inloggen met magische links wilt zonder veel aangepaste code, kun je de schermen en logica in de visuele editors bouwen en het nu proberen.