Polski

tryb gościa
użytkownicy anonimowi
konwersja użytkowników

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

Dowiedz się, jak zaimplementować tryb gościa i konwertować anonimowych użytkowników na użytkowników Logto, korzystając z trójfazowego schematu: zarządzanie sesjami gościa, uwierzytelnienie za pomocą OIDC oraz bezpieczne łączenie danych gościa z kontem użytkownika.

Yijun

Developer

1/9/2026

Przestań tracić tygodnie na uwierzytelnianie użytkowników

Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.

Rozpocznij

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:

Generuje identyfikator gościa (np. UUID)
Zwraca go jako ciasteczko lub JWT
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:

Zweryfikuj token dostępu — uzyskaj user ID. Zobacz Weryfikacja tokenów dostępu, jak to zrobić z Logto.
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:

Połącz dane gościa z kontem użytkownika
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:

Gość (twoja aplikacja) → zarządzanie sesjami przed rejestracją
Uwierzytelnienie (Logto) → obsługa rejestracji i logowania
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.

Dlaczego w Logto nie ma „anonimowego logowania”#

Trójfazowe rozwiązanie#

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

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

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

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

Podsumowanie#

Dlaczego w Logto nie ma „anonimowego logowania”#

Trójfazowe rozwiązanie#

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

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

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

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

Podsumowanie#

Dlaczego w Logto nie ma „anonimowego logowania”

Trójfazowe rozwiązanie

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

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

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

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

Podsumowanie

Dlaczego w Logto nie ma „anonimowego logowania”

Trójfazowe rozwiązanie

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

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

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

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

Podsumowanie