Wie man den Gastmodus (anonyme Nutzer) implementiert und zu Logto-Nutzern konvertiert

Viele Apps lassen Nutzer Funktionen ausprobieren, bevor sie sich registrieren. Denke an Warenkörbe, Dokumenten-Entwürfe oder gespeicherte Einstellungen. Nutzer erwarten, dass dieser "Gastmodus" einfach funktioniert.

Aber wenn du Logto (oder einen anderen OIDC-Provider) für die Authentifizierung nutzt, fragst du dich vielleicht: Wie gehe ich mit diesen anonymen Nutzern um?

Die kurze Antwort: Logto übernimmt die Authentifizierung, deine App kümmert sich um die Gast-Sitzungen. Das sind getrennte Anliegen.

In diesem Artikel zeige ich dir ein einfaches Drei-Phasen-Muster, um den Gastmodus mit Logto zu implementieren. Du lernst, wie du:

• Gast-Sitzungen in deinem Backend verwaltest
• Gästen die Registrierung über Logto ermöglichst
• Gastdaten mit dem echten Benutzerkonto zusammenführst

Warum es in Logto kein "anonymes Login" gibt#

Du erwartest vielleicht, dass Logto eine Funktion für "anonymes Login" hat. Sowas wie: API aufrufen, ein Token erhalten, keine Nutzerinteraktion nötig.

Aber so funktioniert OIDC nicht. Hier ist der Grund:

OIDC basiert auf der Zustimmung des Nutzers. Der Kern ist, zu verifizieren: "Wer ist diese Person?" Ein anonymes Token würde bedeuten: "Das ist irgendjemand, aber wir wissen nicht wer" – was dem Sinn widerspricht.

Stelle es dir so vor:

• Authentifizierung = Identität nachweisen ("Wer bist du?")
• Sitzungsverfolgung = Handlungen merken ("Was hast du getan?")

Der Gastmodus ist Sitzungsverfolgung, keine Authentifizierung. Also gehört das nicht zu deinem Auth-System.

Das ist eigentlich eine gute Nachricht. Es bedeutet, du hast eine klare Trennung:

• Logto übernimmt die Identität (Registrierung, Login, Tokens)
• Deine App übernimmt die Gast-Sitzungen (bevor eine Identität existiert)

Lass jedes System das tun, wofür es gedacht ist.

Die Drei-Phasen-Lösung#

Hier das Muster: Gast → Auth → Zusammenführen

Phase 1: Gast-Sitzungen ohne Authentifizierung verwalten#

Dein Backend erstellt und verwaltet Gast-Sitzungen. Logto ist hier noch nicht beteiligt.

Wenn ein Nutzer eine bedeutende Aktion ausführt (z. B. etwas in den Warenkorb legt), macht dein Backend:

1. Generiert eine Gast-ID (z. B. UUID)
2. Gibt sie als Cookie oder JWT zurück
3. Speichert Nutzeraktionen unter dieser Gast-ID

Halte es einfach. Eine guest_sessions-Tabelle mit guest_id, data und created_at reicht aus.

Phase 2: Nutzer mit Logto anmelden lassen#

Wenn der Nutzer auf "Registrieren" oder "Anmelden" klickt, löse den Standard-Logto-OIDC-Flow aus.

Die Gast-ID bleibt währenddessen im Cookie/Speicher. Nach erfolgreicher Authentifizierung hat dein Frontend jetzt:

• Ein Access Token von Logto (Nutzeridentität)
• Die vorherige Gast-ID (Gastdaten)

Phase 3: Gastdaten sicher mit authentifizierten Nutzern zusammenführen#

Jetzt verbindest du die Punkte. Rufe deine Backend-API mit beidem auf:

Dein Backend muss beide Tokens validieren, bevor zusammengeführt wird:

1. Access Token validieren → extrahiere Nutzer-ID. Siehe Access Tokens validieren für Infos mit Logto.
2. Gast-ID prüfen → bestätige, dass es eine echte Gast-Sitzung ist, die dein Backend ausgestellt hat. Das ist entscheidend – vertraue niemals einfach einer Gast-ID vom Client ohne Verifizierung.

Erst wenn beide Prüfungen bestehen:

3. Gastdaten mit dem Nutzerkonto zusammenführen
4. Gast-Sitzung ungültig machen

Die Logik des Zusammenführens hängt von deinem Geschäft ab. Warenkorb? Artikel kombinieren. Dokumenten-Entwurf? Besitz übertragen. Das entscheidest du.

So sicherst du deinen Merge-Endpoint mit Token-Validierung ab#

Der Merge-Endpoint ist eine sensible Operation. Beachte unbedingt Folgendes:

• Immer das Access Token prüfen. Lies die Nutzer-ID nie einfach aus dem Request-Body. Decodiere und überprüfe das JWT. So geht's mit Logto.
• Immer die Gast-ID prüfen. Schau, dass sie in deiner Datenbank existiert und nicht abgelaufen ist. Falls sie als JWT ausgegeben wurde, prüfe die Signatur.
• Authentifizierung erforderlich. Der Merge-Endpoint muss Anfragen ohne gültiges Access Token ablehnen.
• Setze eine Gültigkeitsdauer (TTL) für Gast-Sitzungen. Bereinige verwaiste Sitzungen nach 30 Tagen (oder was für deine App Sinn macht).

Fazit#

Gastmodus mit Logto folgt einem einfachen Muster:

1. Gast (deine App) → Sitzungen verwalten, bevor sich Nutzer registrieren
2. Auth (Logto) → Registrierung und Login verwalten
3. Merge (deine App) → Gastdaten mit echten Nutzern verbinden

Dieses Muster funktioniert mit jedem OIDC-Provider, nicht nur mit Logto. Der Schlüssel ist: Authentifizierung und Sitzungsverfolgung sind getrennte Anliegen. Lass jedes System das tun, wofür es gebaut wurde.