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

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

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

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

В этой статье я покажу простой трёхфазный паттерн реализации гостевого режима c 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#

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

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

• Access token от Logto (идентификация пользователя)
• прошлый guest ID (гостевые данные)

Фаза 3: Безопасное слияние гостевых данных с аккаунтами#

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

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

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

Только после успешной проверки:

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

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

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

Точка слияния — чувствительная операция. Следи за:

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

Заключение#

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

1. Гость (твоё приложение) → управление сессиями до регистрации
2. Auth (Logto) → регистрация и вход
3. Merge (твоё приложение) → привязка гостевых данных к пользователю

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