Jak zaimplementować tryb gościa (użytkownicy anonimowi) z 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 zadziała.

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

Krótka odpowiedź: Logto zajmuje się uwierzytelnianiem, twoja aplikacja zarządza sesjami gościa. To dwa oddzielne zagadnienia.

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

• Zarządzać sesjami gościa w backendzie
• Pozwalać gościom na rejestrację przez Logto
• Łączyć dane gościa z prawdziwym kontem użytkownika

Dlaczego nie ma "logowania anonimowego" w Logto#

Możesz się spodziewać, że Logto ma funkcję "logowania anonimowego". Coś w stylu: wywołaj API, dostaniesz token, nie jest potrzebne żadne działanie użytkownika.

Ale OIDC tak nie działa. Oto dlaczego:

OIDC opiera się na zgodzie użytkownika. Chodzi o to, żeby zweryfikować "kim jest ta osoba?" Anonimowy token oznaczałby "to ktoś, ale nie wiemy kto" — a to przeczy założeniom.

Pomyśl o tym tak:

• Uwierzytelnianie = dowód tożsamości ("kim jesteś?")
• Śledzenie sesji = zapamiętywanie działań ("co zrobiłeś?")

Tryb gościa to śledzenie sesji, a nie uwierzytelnianie. Dlatego nie należy do systemu autoryzacji.

Ale to dobra wiadomość. To oznacza, że masz wyraźny podział:

• Logto obsługuje tożsamość (rejestracja, logowanie, tokeny)
• Twoja aplikacja zarządza sesjami gościa (przed uzyskaniem tożsamości)

Niech każdy system robi to, do czego został zaprojektowany.

Trójfazowe rozwiązanie#

Oto schemat: Gość → Uwierzytelnienie → Połączenie

Faza 1: Obsługa sesji gościa bez uwierzytelniania#

Twój backend tworzy i zarządza sesjami gościa. Logto tu jeszcze nie uczestniczy.

Kiedy użytkownik wykonuje istotne działanie (np. dodaje do koszyka), backend:

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

Zachowaj prostotę. Tabela guest_sessions z polami guest_id, data i created_at wystarczy.

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

Gdy użytkownik kliknie "Rejestracja" lub "Logowanie", uruchom standardowy proces OIDC Logto.

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

• Access token z Logto (tożsamość użytkownika)
• Guest ID (dane gościa)

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

Teraz połącz wszystko. Wywołaj API backendowe z obiema informacjami:

Backend musi zweryfikować oba tokeny przed połączeniem:

1. Zweryfikuj access token → wyciągnij user ID. Zobacz Weryfikacja access tokenów, jak zrobić to z Logto.
2. Zweryfikuj guest ID → potwierdź, że to prawdziwa sesja gościa wygenerowana przez twój backend. To kluczowe — nigdy nie ufaj guest ID z klienta bez weryfikacji.

Dopiero po pozytywnej weryfikacji obu:

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

Logika łączenia zależy od biznesu. Koszyk? Połącz produkty. Szkice dokumentów? Przenieś własność. Decyzja należy do ciebie.

Jak zabezpieczyć endpoint do łączenia tokenów#

Endpoint do łączenia to operacja wrażliwa. Zapamiętaj, żeby:

• Zawsze weryfikować access token. Nie czytaj user ID z body żądania. Odszyfruj i zweryfikuj JWT. Tak to zrobić z Logto.
• Zawsze weryfikować guest ID. Sprawdź, że istnieje w twojej bazie i nie wygasł. Jeśli wydajesz go jako JWT, zweryfikuj podpis.
• Wymagaj uwierzytelnienia. Endpoint do łączenia powinien odrzucać żądania bez poprawnego access tokena.
• Ustal TTL dla sesji gościa. Sprzątaj porzucone sesje po 30 dniach (lub w innym terminie odpowiednim dla twojej aplikacji).

Podsumowanie#

Tryb gościa z Logto opiera się na prostym schemacie:

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

Ten schemat działa z każdym dostawcą OIDC, nie tylko z Logto. Kluczowe wnioski: uwierzytelnianie i śledzenie sesji to osobne sprawy. Pozwól każdemu systemowi robić to, do czego został stworzony.