Hur man implementerar gästäget (anonyma användare) och konverterar till Logto-användare

Många appar låter användare prova funktioner innan de registrerar sig. Tänk på varukorgar, dokumentutkast eller sparade inställningar. Användarna förväntar sig att detta "gästäge" bara ska fungera.

Men om du använder Logto (eller någon annan OIDC-leverantör) för autentisering kanske du undrar: hur hanterar jag dessa anonyma användare?

Det korta svaret: Logto hanterar autentisering, din app hanterar gästsessioner. Det är separata saker.

I den här artikeln visar jag ett enkelt trefasigt mönster för att implementera gästäge med Logto. Du kommer att lära dig hur du:

• Hanterar gästsessioner i din backend
• Låter gäster registrera sig via Logto
• Slår ihop gästdata med det riktiga användarkontot

Varför det inte finns något "anonym inloggning" i Logto#

Du kanske förväntar dig att Logto har en funktion för "anonym inloggning". Något i stil med: anropa ett API, få en token, ingen användarinteraktion krävs.

Men så fungerar inte OIDC. Så här är det:

OIDC bygger på användarens samtycke. Poängen är att verifiera "vem är den här personen?" En anonym token skulle betyda "det här är någon, men vi vet inte vem" — vilket förlorar hela syftet.

Tänk på det så här:

• Autentisering = bevisa identitet ("vem är du?")
• Sessionhantering = minnas handlingar ("vad gjorde du?")

Gästäge handlar om sessionhantering, inte autentisering. Så det hör inte hemma i ditt autentiseringssystem.

Det här är faktiskt goda nyheter. Det betyder att du har en tydlig uppdelning:

• Logto hanterar identitet (registrering, inloggning, tokens)
• Din app hanterar gästsessioner (innan identitet finns)

Låt varje system göra det som det är designat för.

Den trefasiga lösningen#

Här är mönstret: Gäst → Auth → Sammanfoga

Fas 1: Hantera gästsessioner utan autentisering#

Din backend skapar och hanterar gästsessioner. Logto är inte inblandat än.

När en användare gör en meningsfull handling (som att lägga till i varukorgen), gör din backend:

1. Genererar ett guest ID (t.ex. UUID)
2. Returnerar det som cookie eller JWT
3. Sparar användarens handlingar under detta guest ID

Håll det enkelt. Ett guest_sessions-tabell med guest_id, data och created_at räcker.

Fas 2: Låt användare logga in med Logto#

När användaren klickar på "Registrera" eller "Logga in" kör du det vanliga Logto OIDC-flödet.

Guest ID ligger kvar i cookie/lagring under denna process. Efter lyckad autentisering har din frontend nu:

• Ett access token från Logto (användaridentitet)
• Guest ID från tidigare (gästdata)

Fas 3: Slå ihop gästdata till autentiserade användare#

Nu kopplar du ihop allt. Anropa din backend-API med båda:

Din backend måste validera båda tokens innan du slår ihop:

1. Validera access token → extrahera användar-ID. Se Validera access tokens för hur du gör detta med Logto.
2. Validera guest ID → bekräfta att det är en riktig gästsession din backend har skapat. Detta är kritiskt — lita aldrig på ett guest ID från klienten utan verifiering.

Först när båda valideringarna lyckas:

3. Slå ihop gästdata till användarkontot
4. Ogiltigförklara gästsessionen

Vilka data som ska slås ihop beror på din affärslogik. Varukorg? Kombinera artiklar. Dokumentutkast? Byt ägare. Det bestämmer du.

Så här säkrar du din merge-endpoint med tokenvalidering#

Merge-endpointen är en känslig åtgärd. Några saker att tänka på:

• Validera alltid access token. Läs aldrig bara användar-ID från begäran. Avkoda och verifiera JWT. Så här gör du med Logto.
• Validera alltid guest ID. Kontrollera att det finns i din databas och inte har gått ut. Om du gav ut det som JWT, verifiera signaturen.
• Kräv autentisering. Merge-endpointen ska neka begäranden utan giltigt access token.
• Sätt en TTL för gästsessioner. Rensa bort övergivna sessioner efter 30 dagar (eller vad som passar din app).

Slutsats#

Gästäge med Logto följer ett enkelt mönster:

1. Gäst (din app) → hantera sessioner innan användaren registrerar sig
2. Auth (Logto) → hantera registrering och inloggning
3. Sammanfoga (din app) → koppla gästdata till riktiga användare

Detta mönster fungerar med alla OIDC-leverantörer, inte bara Logto. Den viktigaste insikten är: autentisering och sessionhantering är separata saker. Låt varje system sköta det det är byggt för.