Wie man den Gastmodus (anonyme Benutzer) mit Logto implementiert

Viele Apps lassen Benutzer Funktionen ausprobieren, bevor sie sich registrieren. Denke an Einkaufswagen, Dokumententwürfe oder gespeicherte Einstellungen. Benutzer erwarten, dass dieser "Gastmodus" einfach funktioniert.

Aber wenn du Logto (oder einen anderen OIDC-Anbieter) zur Authentifizierung verwendest, fragst du dich vielleicht: Wie gehe ich mit diesen anonymen Benutzern um?

Die kurze Antwort: Logto übernimmt die Authentifizierung, deine App verwaltet die Gast-Sessions. Das sind getrennte Bereiche.

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

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

Warum es in Logto kein "anonymes Login" gibt#

Du würdest vielleicht erwarten, dass Logto eine Funktion für "anonymes Login" hat. So etwas wie: Eine API aufrufen, ein Token erhalten, keine Benutzerinteraktion erforderlich.

Aber so funktioniert OIDC nicht. Hier ist der Grund:

OIDC basiert auf Benutzereinwilligung. Das Ziel ist, zu überprüfen: "Wer ist diese Person?" Ein anonymes Token würde bedeuten: "Das ist jemand, aber wir wissen nicht wer" – was dem Zweck widerspricht.

Stell es dir so vor:

• Authentifizierung = Identität nachweisen ("Wer bist du?")
• Session-Tracking = Aktionen merken ("Was hast du getan?")

Der Gastmodus dreht sich um Session-Tracking, nicht Authentifizierung. Deshalb gehört er nicht in dein Auth-System.

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

• Logto kümmert sich um Identität (Registrierung, Anmeldung, Tokens)
• Deine App verwaltet Gast-Sessions (bevor eine Identität existiert)

Lass jedes System das tun, wofür es entworfen wurde.

Die Drei-Phasen-Lösung#

Das Muster lautet: Gast → Auth → Merge

Phase 1: Gast-Sessions ohne Authentifizierung verwalten#

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

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

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

Halte es einfach. Eine guest_sessions-Tabelle mit guest_id, data und created_at genügt.

Phase 2: Benutzer mit Logto anmelden lassen#

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

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

• Ein Access-Token von Logto (Benutzeridentität)
• Die Gast-ID von davor (Gastdaten)

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

Nun verbindest du alles. Rufe deine Backend-API mit beiden Werten auf:

Dein Backend muss beide Token validieren, bevor es zusammenführt:

1. Access-Token validieren → extrahiere Benutzer-ID. Siehe Access-Tokens validieren für die Umsetzung mit Logto.
2. Gast-ID validieren → Bestätige, dass es eine echte Gast-Session ist, die dein Backend ausgegeben hat. Das ist entscheidend – vertraue keiner Gast-ID, die vom Client kommt, ohne Verifizierung.

Nur wenn beide Validierungen bestehen:

3. Gastdaten zusammenführen mit dem Benutzerkonto
4. Gast-Session ungültig machen

Die Logik zum Zusammenführen hängt von deinem Geschäft ab. Warenkorb? Artikel kombinieren. Dokumententwürfe? Besitz übertragen. Du entscheidest.

So schützt du deinen Merge-Endpoint mit Token-Validierung#

Der Merge-Endpoint ist eine sensible Funktion. Beachte folgendes:

• Access-Token immer validieren. Lies die Benutzer-ID nicht einfach aus dem Request-Body. JWT dekodieren und verifizieren. Hier steht, wie du das mit Logto machst.
• Gast-ID immer validieren. Prüfe, dass sie in deiner Datenbank existiert und nicht abgelaufen ist. Wenn du sie als JWT ausgibst, überprüfe die Signatur.
• Authentifizierung erforderlich. Der Merge-Endpoint sollte Anfragen ohne gültigen Access-Token ablehnen.
• Setze eine Lebensdauer (TTL) für Gast-Sessions. Bereinige verwaiste Sessions nach 30 Tagen (oder was für deine App sinnvoll ist).

Fazit#

Der Gastmodus mit Logto folgt einem einfachen Muster:

1. Gast (deine App) → Sessions verwalten, bevor sich Benutzer anmelden
2. Auth (Logto) → Registrierung und Anmeldung abwickeln
3. Merge (deine App) → Gastdaten mit realen Benutzern verknüpfen

Dieses Muster funktioniert mit jedem OIDC-Anbieter, nicht nur Logto. Die wichtigste Erkenntnis ist: Authentifizierung und Session-Tracking sind getrennte Aufgaben. Lasse jedes System das tun, wofür es gebaut wurde.