Подсистема «Идентификация и регистрация»¶

Инфраструктурный auth-сервис. Встраивается во все точки взаимодействия: терминалы, мобильные устройства, сенсорные стойки, LED. Выдаёт токены, проверяет credentials, обслуживает OAuth 2.0 через внешних провайдеров. Не имеет собственного клиентского фасада — его используют все подсистемы.

Единая модель пользователя¶

Пользователь платформы — одна запись в базе данных (User), которая может быть в гостевом или авторизованном состоянии:

Гость — создан при первом сканировании QR-кода, имеет guest_id, без OAuth-данных
Авторизованный — тот же пользователь, у которого заполнились OAuth-данные после авторизации

Результаты всех активностей (LED-сессии, ПрофСтарт, анкеты) всегда привязаны к id пользователя. При переходе из гостевого режима в авторизованный перенос данных не требуется — всё уже привязано к одной записи.

Способы авторизации¶

OAuth 2.0 через внешних провайдеров:
Яндекс ID (имя, email, аватар, дата рождения)
VK ID (имя, email, аватар, пол, дата рождения)
Гостевой режим — без авторизации, по QR-коду, с возможностью последующей авторизации
Локальная регистрация по ID/паролю не поддерживается

Создание и авторизация пользователя¶

Сценарий 1: Повторное сканирование QR (авторизованный пользователь)¶

Пользователь сканирует QR-код на терминале
Браузер отправляет access token из локального хранилища
Сервер проверяет токен, находит User по user_id из токена
Пользователь узнаётся — новая запись не создаётся, переход в активность или профиль

Сценарий 2: Первый контакт — выбор OAuth¶

Пользователь сканирует QR-код на терминале
Браузер не содержит токена — сервер возвращает URL экрана выбора
Пользователь видит экран: «Войти через OAuth или продолжить как гость?» с чекбоксом согласия на ПДн
Пользователь ставит галочку согласия (обязательная, со ссылкой на текст)
Нажимает кнопку провайдера (Яндекс ID / VK ID)
Сервер записывает ConsentAcceptance, редирект на провайдера
Авторизация у провайдера, callback с кодом
Сервер обменивает код на данные пользователя
Создаётся User со status = active, заполняются OAuth-поля
Выдача JWT, переход в активность

Сценарий 3: Первый контакт — выбор «Гость»¶

Пользователь сканирует QR-код на терминале
Браузер не содержит токена — сервер возвращает URL экрана выбора
Пользователь видит экран: «Войти через OAuth или продолжить как гость?» с чекбоксом согласия на ПДн
Пользователь ставит галочку согласия (обязательная)
Нажимает «Продолжить как гость»
Сервер записывает ConsentAcceptance, создаёт User со status = guest, генерирует guest_id и guest_expires_at (24 часа)
guest_id сохраняется в браузере/локальном хранилище устройства
Все результаты привязываются к id пользователя

Сценарий 4: Гость авторизуется позже¶

В личном кабинете гость видит баннер «Авторизуйтесь» с чекбоксом согласия
Пользователь ставит галочку, нажимает «Войти через OAuth»
Сервер записывает ConsentAcceptance, браузер передаёт guest_id
Редирект на провайдера, авторизация, callback с кодом
Сервер находит User по guest_id (status=guest)
Заполняются OAuth-поля, status меняется на active, guest_expires_at обнуляется
guest_id сохраняется для истории
Выдача JWT, данные уже привязаны

Токены и сессии¶

Тип	Формат	Срок жизни	Описание
Access token	JWT	30 минут	Проверяется локально подсистемами, содержит `user_id` и `status`
Refresh token	opaque	7 дней	Хранится на сервере, для обновления access token

Производительность: проверка токена — не более 2 секунд, до 50 одновременных сессий.

Гостевой режим¶

Гость сканирует QR-код → создаётся User со status = guest, guest_id сохраняется в браузере
При сканировании QR на другом терминале браузер отправляет guest_id → система узнаёт того же гостя по записи User
Все результаты гостя привязываются к id этой записи
Авторизация: если в рамках гостевого режима пользователь авторизуется через OAuth, OAuth-поля заполняются у той же записи — данные уже привязаны, перенос не нужен
Истечение: если 24 часа прошли без авторизации, guest_expires_at истекает. Пользователь остаётся в статусе guest, данные остаются в системе (аналитика не удаляется), но связать этого пользователя с будущей OAuth-авторизацией нельзя

Оффлайн-режим (нет Интернета у пользователя)¶

Отдельные точки доступа (роутеры) раздают гостевой Wi-Fi
На гостевом Wi-Fi разрешён доступ только к URL системы и сервисам VK/Яндекс (для OAuth)
Пользователь подключается к Wi-Fi, сканирует QR с терминала → авторизация через OAuth работает
Если гостевой Wi-Fi недоступен — только гостевой режим без авторизации

API для интеграции¶

Централизованный auth-сервис предоставляет API для всех подсистем:

Endpoint	Назначение
`GET /qr/scan`	Сканирование QR: если передан токен — узнаёт пользователя, если нет — возвращает URL экрана выбора
`POST /qr/scan/guest`	Создание гостевого User (status=guest, guest_id)
`GET /authorize`	Начало OAuth-флоу (редирект на провайдера). Поддерживает `guest_id` для привязки
`GET /callback`	Callback от OAuth-провайдера
`POST /token/refresh`	Обновление access token по refresh token
`GET /token/validate`	Проверка JWT (для подсистем, которые не могут проверять локально)
`GET /userinfo`	Данные пользователя по токену

Хранение данных¶

PostgreSQL
Раздельное хранение:
Пользователи (гости и авторизованные в одной таблице)
Согласия пользователя

Масштаб и производительность¶

До 50 одновременных сессий
До 10 000 пользователей в системе
Проверка токена — не более 2 секунд

Особые сценарии¶

Пользователь заблокирован в Яндекс/VK: может использовать другого провайдера
Провайдер OAuth недоступен: может использовать другого провайдера или гостевой режим
Деактивация аккаунта: действие администратора, вход невозможен, данные сохранены
Обезличивание: возврат информации без данных пользователя, только идентификатор

Взаимодействие¶

Обслуживает все подсистемы и клиентские интерфейсы
Передаёт данные профиля в Цифровой профиль
Сенсорные стойки подключаются к единому auth через QR-код