Как реализовать гостевой режим (анонимные пользователи) с Logto

Многие приложения позволяют пользователям попробовать функции до регистрации. Например, корзины покупок, черновики документов или сохранённые настройки. Пользователи ожидают, что "гостевой режим" будет работать.

Но если ты используешь Logto (или любого OIDC провайдера) для аутентификации, ты можешь задаться вопросом: как обрабатывать таких анонимных пользователей?

Коротко: Logto отвечает за аутентификацию, твое приложение — за гостевые сессии. Это разные задачи.

В этой статье я покажу простой трёхфазный паттерн для реализации гостевого режима с Logto. Ты узнаешь, как:

• Управлять гостевыми сессиями на сервере
• Позволять гостям регистрироваться через Logto
• Объединять гостевые данные с реальным аккаунтом пользователя

Почему нет "анонимного входа" в Logto#

Можно ожидать, что у Logto есть функция "анонимного входа". Например: вызвал API, получил токен, без взаимодействия пользователя.

Но OIDC так не работает. Почему:

OIDC строится вокруг согласия пользователя. Вся суть — проверить "кто этот человек?" Анонимный токен означал бы "это кто-то, но мы не знаем кто" — что сводит смысл на нет.

Подумай так:

• Аутентификация = подтверждение личности ("кто ты?")
• Отслеживание сессии = запоминание действий ("что ты сделал?")

Гостевой режим — это про отслеживание сессии, а не аутентификацию. Поэтому это не должно быть частью системы аутентификации.

И это хорошая новость. Потому что теперь у тебя чёткое разделение:

• Logto отвечает за личность (регистрация, вход, токены)
• Твоё приложение — за гостевые сессии (до появления личности)

Пусть каждая система делает то, для чего она создана.

Трёхфазное решение#

Схема такая: Гость → Аутентификация → Слияние

Фаза 1: Управление гостевыми сессиями без аутентификации#

Твой сервер создает и управляет гостевыми сессиями. Logto здесь ещё не участвует.

Когда пользователь совершает значимое действие (например, добавляет в корзину), твой бэкенд:

1. Генерирует guest ID (например, UUID)
2. Возвращает его как cookie или JWT
3. Сохраняет действия пользователя по этому guest ID

Достаточно простой таблицы guest_sessions с guest_id, data и created_at.

Фаза 2: Авторизация пользователя через Logto#

Когда пользователь жмёт "Зарегистрироваться" или "Войти", запускается стандартный OIDC-флоу Logto.

Guest ID продолжает храниться в cookie/хранилище на этом этапе. После успешной аутентификации у фронтенда есть:

• Access token из Logto (личность пользователя)
• Guest ID с прошлых действий (гостевые данные)

Фаза 3: Безопасное объединение гостевых данных с пользователем#

Теперь нужно связать гостевые данные с пользователем. Вызови бэкенд API с двумя параметрами:

Бэкенд должен валидировать оба токена перед объединением:

1. Проверить access token → извлечь user ID. Смотри Проверка access token'ов, как это делать с Logto.
2. Проверить guest ID → убедиться, что это настоящая гостевая сессия, выданная твоим бэкендом. Это важно — ни в коем случае не доверяй guest ID от клиента без верификации.

Только когда оба условия выполнены:

3. Перенести гостевые данные в аккаунт пользователя
4. Удалить гостевую сессию

Логика объединения зависит от твоего приложения. Корзина? Объединить товары. Черновики документов? Передать права владельца. Решай сам.

Как защитить endpoint слияния через проверку токенов#

Endpoint для слияния — чувствительная операция. Важно помнить:

• Всегда проверяй access token. Не читай user ID из тела запроса. Декодируй и верифицируй JWT. Вот как cделать это с Logto.
• Всегда проверяй guest ID. Убедись, что он есть в базе и не просрочен. Если это JWT, проверь подпись.
• Требуй аутентификацию. Endpoint слияния должен отклонять запросы без access token.
• Задай TTL для гостевых сессий. Чисть заброшенные сессии через 30 дней (или другой подходящий срок).

Вывод#

Гостевой режим с Logto реализуется по простой схеме:

1. Гость (твоё приложение) → управление сессиями до регистрации пользователей
2. Аутентификация (Logto) → регистрация и вход
3. Слияние (твоё приложение) → объединение гостевых данных с личным аккаунтом

Этот паттерн работает с любым OIDC-провайдером, не только Logto. Главное — аутентификация и отслеживание сессии это разные задачи. Пусть каждая делает своё.