Nederlands

gastmodus
anonieme gebruikers
gebruikersconversie

Hoe gastmodus (anonieme gebruikers) te implementeren en om te zetten naar Logto-gebruikers

Leer hoe je gastmodus implementeert en converteert naar Logto-gebruikers met een drie-fasenpatroon: gastensessies beheren, authenticeren met OIDC en gastgegevens veilig samenvoegen met gebruikersaccounts.

Yijun

Developer

1/9/2026

Stop met weken verspillen aan gebruikersauthenticatie

Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.

Aan de slag

Veel apps laten gebruikers functies uitproberen voordat ze zich aanmelden. Denk aan winkelwagens, documentconcepten of opgeslagen voorkeuren. Gebruikers verwachten dat deze "gastmodus" gewoon werkt.

Maar als je Logto (of een andere OIDC-provider) gebruikt voor authenticatie, vraag je je misschien af: hoe ga ik om met deze anonieme gebruikers?

Het korte antwoord: Logto regelt de authenticatie, jouw app regelt de gastensessies. Het zijn gescheiden zaken.

In dit artikel laat ik je een eenvoudig drie-fasenpatroon zien om gastmodus te implementeren met Logto. Je leert hoe je:

Gastensessies beheert in je backend
Gasten laat aanmelden via Logto
Gastgegevens samenvoegt met het echte gebruikersaccount

Je zou verwachten dat Logto een functie voor "anonieme login" heeft. Zoiets als: een API aanroepen, een token krijgen, geen gebruikersactie nodig.

Maar zo werkt OIDC niet. Hier is waarom:

OIDC draait om gebruikersinstemming. Het hele punt is om te verifiëren: "wie is deze persoon?" Een anoniem token zou betekenen "dit is iemand, maar we weten niet wie" — dat ondermijnt het doel.

Zie het zo:

Authenticatie = identiteit bewijzen ("wie ben je?")
Sessie bijhouden = acties onthouden ("wat heb je gedaan?")

Gastmodus draait om sessie bijhouden, niet om authenticatie. Het hoort dus niet bij je authenticatiesysteem.

Dit is eigenlijk goed nieuws. Het betekent dat je een duidelijke scheiding hebt:

Logto regelt identiteit (aanmelden, inloggen, tokens)
Jouw app regelt gastensessies (voordat er een identiteit is)

Laat elk systeem doen waar het voor bedoeld is.

De drie-fasenoplossing

Hier is het patroon: Gast → Auth → Samenvoegen

Fase 1: Gastensessies beheren zonder authenticatie

Je backend maakt en beheert gastensessies. Logto komt nog niet in beeld.

Wanneer een gebruiker een betekenisvolle actie uitvoert (zoals iets toevoegen aan een winkelwagen), doet je backend het volgende:

Genereert een gast-ID (bijv. UUID)
Geeft deze terug als cookie of JWT
Slaat gebruikersacties op onder deze gast-ID

Hou het simpel. Een guest_sessions tabel met guest_id, data en created_at is genoeg.

Fase 2: Gebruikers laten aanmelden met Logto

Wanneer de gebruiker op "Aanmelden" of "Inloggen" klikt, start je de standaard Logto OIDC-flow.

De gast-ID blijft in de cookie/opslag tijdens dit proces. Na succesvolle authenticatie heeft je frontend nu:

Een toegangstoken van Logto (gebruikersidentiteit)
De gast-ID van eerder (gastgegevens)

Fase 3: Gastgegevens veilig samenvoegen met geauthenticeerde gebruikers

Nu de puntjes verbinden. Roep je backend-API aan met beide:

Je backend moet beide tokens valideren voordat je samenvoegt:

Valideer het toegangstoken → haal gebruikers-ID eruit. Zie Access tokens valideren voor hoe je dit doet met Logto.
Valideer de gast-ID → bevestig dat het een echte gastensessie is uitgegeven door jouw backend. Dit is cruciaal — vertrouw nooit zomaar een gast-ID van de client zonder verificatie.

Pas nadat beide validaties slagen:

Voeg gastgegevens samen met het gebruikersaccount
Maak de gastensessie ongeldig

De logica voor samenvoegen hangt af van je business. Winkelwagen? Combineer items. Documentconcepten? Zet eigenaarschap over. Jij beslist.

Hoe beveilig je je merge-endpoint met tokenvalidatie

Het merge-endpoint is een gevoelige operatie. Een paar dingen om in gedachten te houden:

Valideer altijd het toegangstoken. Lees niet zomaar de gebruikers-ID uit het request body. Decodeer en verifieer de JWT. Zo doe je dit met Logto.
Valideer altijd de gast-ID. Check of die bestaat in je database en nog niet is verlopen. Als je hem uitgeeft als JWT, verifieer de handtekening.
Vereis authenticatie. Het merge-endpoint moet verzoeken zonder geldig toegangstoken weigeren.
Stel een TTL in voor gastensessies. Ruim verlaten sessies op na 30 dagen (of wat logisch is voor jouw app).

Conclusie

Gastmodus met Logto volgt een eenvoudig patroon:

Gast (jouw app) → beheer sessies voordat gebruikers zich aanmelden
Auth (Logto) → beheer aanmelden en inloggen
Samenvoegen (jouw app) → koppel gastgegevens aan echte gebruikers

Dit patroon werkt met elke OIDC-provider, niet alleen Logto. Het belangrijkste inzicht is: authenticatie en sessie tracking zijn gescheiden verantwoordelijkheden. Laat elk systeem doen waarvoor het gebouwd is.

Waarom er geen "anonieme login" is in Logto#

De drie-fasenoplossing#

Fase 1: Gastensessies beheren zonder authenticatie#

Fase 2: Gebruikers laten aanmelden met Logto#

Fase 3: Gastgegevens veilig samenvoegen met geauthenticeerde gebruikers#

Hoe beveilig je je merge-endpoint met tokenvalidatie#

Conclusie#

Waarom er geen "anonieme login" is in Logto#

De drie-fasenoplossing#

Fase 1: Gastensessies beheren zonder authenticatie#

Fase 2: Gebruikers laten aanmelden met Logto#

Fase 3: Gastgegevens veilig samenvoegen met geauthenticeerde gebruikers#

Hoe beveilig je je merge-endpoint met tokenvalidatie#

Conclusie#

Waarom er geen "anonieme login" is in Logto

De drie-fasenoplossing

Fase 1: Gastensessies beheren zonder authenticatie

Fase 2: Gebruikers laten aanmelden met Logto

Fase 3: Gastgegevens veilig samenvoegen met geauthenticeerde gebruikers

Hoe beveilig je je merge-endpoint met tokenvalidatie

Conclusie

Waarom er geen "anonieme login" is in Logto

De drie-fasenoplossing

Fase 1: Gastensessies beheren zonder authenticatie

Fase 2: Gebruikers laten aanmelden met Logto

Fase 3: Gastgegevens veilig samenvoegen met geauthenticeerde gebruikers

Hoe beveilig je je merge-endpoint met tokenvalidatie

Conclusie