Jak zaimplementować tryb gościa (użytkownicy anonimowi) i konwersję na użytkowników Logto

Wiele aplikacji pozwala użytkownikom wypróbować funkcje przed rejestracją. Pomyśl o koszykach zakupowych, szkicach dokumentów czy zapisanych preferencjach. Użytkownicy oczekują, że taki „tryb gościa” po prostu będzie działał.

Ale jeśli używasz Logto (lub dowolnego dostawcy OIDC) do uwierzytelniania, możesz się zastanawiać: jak obsłużyć tych anonimowych użytkowników?

Krótka odpowiedź: Logto obsługuje uwierzytelnianie, twoja aplikacja obsługuje sesje gościa. To osobne zagadnienia.

W tym artykule pokażę ci prosty, trójfazowy schemat implementacji trybu gościa z Logto. Dowiesz się, jak:

• Zarządzać sesjami gościa w backendzie
• Pozwolić gościom zarejestrować się przez Logto
• Połączyć dane gościa z prawdziwym kontem użytkownika

Dlaczego w Logto nie ma „anonimowego logowania”#

Możesz się spodziewać, że Logto ma funkcję „anonimowego logowania”. Coś w stylu: wywołaj API, pobierz token, bez interakcji użytkownika.

Ale OIDC nie działa w ten sposób. Oto dlaczego:

OIDC opiera się na zgodzie użytkownika. Cała idea polega na weryfikowaniu „kim jest ta osoba?”. Token anonimowy oznaczałby „to jest ktoś, ale nie wiemy kto” — co przeczy celowi.

Pomyśl o tym tak:

• Uwierzytelnienie = potwierdzenie tożsamości („kim jesteś?”)
• Śledzenie sesji = zapamiętywanie działań („co zrobiłeś?”)

Tryb gościa dotyczy śledzenia sesji, nie uwierzytelniania. Dlatego nie należy do twojego systemu authentication.

To właściwie dobra wiadomość. Daje to wyraźny podział:

• Logto obsługuje tożsamość (rejestracja, logowanie, tokeny)
• Twoja aplikacja obsługuje sesje gościa (zanim powstanie tożsamość)

Pozwól każdemu systemowi robić to, do czego jest przeznaczony.

Trójfazowe rozwiązanie#

Schemat wygląda tak: Gość → Uwierzytelnienie → Połączenie

Faza 1: Zarządzanie sesjami gościa bez uwierzytelniania#

Twój backend tworzy i zarządza sesjami gościa. Logto nie bierze jeszcze udziału.

Gdy użytkownik wykonuje istotne działanie (np. dodanie do koszyka), twój backend:

1. Generuje identyfikator gościa (np. UUID)
2. Zwraca go jako ciasteczko lub JWT
3. Przechowuje działania użytkownika pod tym guest ID

Nie komplikuj. Wystarczy tabela guest_sessions z polami guest_id, data i created_at.

Faza 2: Pozwól użytkownikom zalogować się przez Logto#

Gdy użytkownik kliknie „Zarejestruj się” lub „Zaloguj się”, uruchom standardowy flow OIDC Logto.

Guest ID pozostaje w ciasteczku/pamięci podczas tego procesu. Po pomyślnym uwierzytelnieniu frontend ma:

• Token dostępu z Logto (tożsamość użytkownika)
• Guest ID z wcześniejszego etapu (dane gościa)

Faza 3: Bezpieczne połączenie danych gościa z zalogowanym użytkownikiem#

Teraz połącz wszystko. Wywołaj API backendowe z obydwoma danymi:

Twój backend musi zweryfikować oba tokeny przed połączeniem:

1. Zweryfikuj token dostępu — uzyskaj user ID. Zobacz Weryfikacja tokenów dostępu, jak to zrobić z Logto.
2. Zweryfikuj guest ID — potwierdź, że jest to prawdziwa sesja gościa wystawiona przez twój backend. To kluczowe — nigdy nie ufaj guest ID wysłanemu z klienta bez weryfikacji.

Po pozytywnej weryfikacji:

3. Połącz dane gościa z kontem użytkownika
4. Unieważnij sesję gościa

Logika połączenia zależy od biznesu. Koszyk? Scal przedmioty. Szkice dokumentów? Przypisz własność. Ty decydujesz.

Jak zabezpieczyć endpoint połączenia przez walidację tokenów#

Endpoint łączenia to wrażliwa operacja. Kilka rzeczy wartych zapamiętania:

• Zawsze waliduj access token. Nie czytaj user ID tylko z requestu! Odszyfruj i zweryfikuj JWT. Zobacz jak zrobić to z Logto.
• Zawsze waliduj guest ID. Sprawdź, że istnieje w bazie i nie wygasł. Jeśli guest ID to JWT, sprawdź sygnaturę.
• Wymagaj uwierzytelnienia. Endpoint musi odrzucać żądania bez ważnego tokenu.
• Ustaw limit czasu życia sesji gościa. Usuwaj opuszczone sesje po 30 dniach (lub jak długo chcesz).

Podsumowanie#

Tryb gościa z Logto to prosty schemat:

1. Gość (twoja aplikacja) → zarządzanie sesjami przed rejestracją
2. Uwierzytelnienie (Logto) → obsługa rejestracji i logowania
3. Połączenie (twoja aplikacja) → powiązanie danych gościa z użytkownikiem

Ten schemat działa z każdym dostawcą OIDC, nie tylko Logto. Kluczowa myśl: uwierzytelnianie i śledzenie sesji to osobne zagadnienia. Pozwól każdemu systemowi robić to, co do niego należy.