Настройка системы уровней доступа и авторизации в VR играх

id: 230 slug: vr-game-access-level-and-authorization-system title_ru: "Настройка системы уровней доступа и авторизации в VR играх" tags: [vr-ar]

Настройка системы уровней доступа и авторизации в VR играх

В корпоративных VR-тренажёрах и образовательных платформах авторизация — не опциональная фича. Трейни не должен видеть результаты коллег. Инструктор должен видеть всех. Администратор — управлять контентом. При этом весь этот контроль доступа должен работать без клавиатуры: в VR нет нативного способа ввести пароль, не снимая шлем.

Специфика авторизации в VR-контексте

Главное ограничение — ввод учётных данных. Стандартный логин/пароль в VR невозможен без виртуальной клавиатуры. Quest.VirtualKeyboard (OpenXR Keyboard Extension XR_META_virtual_keyboard) решает это на Meta-устройствах, но это нативная клавиатура Meta — её нет на Pico или SteamVR. Альтернативные подходы:

• QR-аутентификация: пользователь сканирует QR-код с телефона или монитора через passthrough камеру HMD. Реализуется через ZXing .NET или ML Kit, работает на AR Foundation + Passthrough.
• PIN-код на виртуальной панели: 4–6 цифр через XRGrabInteractable кнопки — работает на любом OpenXR-устройстве.
• SSO через сопряжённое приложение: мобильное приложение-companion авторизует пользователя, передаёт token в VR-приложение через локальную сеть или deeplink (для Quest через adb shell am start).
• Proximity card / NFC: для стационарных VR-стендов — считыватель по USB-HID, обрабатываемый через Input.GetJoystickNames() или нативный плагин.

Архитектура уровней доступа

Для корпоративных VR-платформ строим RBAC (Role-Based Access Control) с ролями: Learner, Instructor, Admin, Guest. Каждая роль определяет:

• доступные сцены/модули (через ScenePermission ScriptableObject)
• возможность просматривать чужие сессии
• право на сброс прогресса
• доступ к аналитике в реальном времени

Данные ролей хранятся на бэкенде. VR-клиент получает JWT token при авторизации, декодирует claims (role, allowed_modules[], organization_id) и строит локальный permission cache. Все проверки — через единый IPermissionService, не разбросанные if (isAdmin) по коду.

Для хранения session token на устройстве: PlayerPrefs не подходит — данные читаются без root на некоторых устройствах. Используем UnityEngine.Windows.File на PC или нативный Android KeyStore через Java plugin для Quest. Токены с exp claim коротко живущие (8 часов), refresh через silent request в фоне.

Мультипользовательские сессии (один Quest, несколько профилей) — отдельная история. Без встроенного user switching в ОС реализуем через собственный экран смены пользователя: выбор аватара + PIN. Профиль хранится в Application.persistentDataPath/profiles/{userId}/ с шифрованием через AES-256 (ключ из KeyStore).

Интеграция с корпоративными системами

Для корпоративных заказчиков типовые требования: интеграция с Active Directory / Azure AD (OAuth 2.0 + OpenID Connect), SSO с корпоративными порталами, выгрузка результатов сессий в LMS (xAPI / SCORM через специализированные адаптеры).

xAPI (Tin Can API) — стандарт для VR-тренажёров: каждое действие пользователя ("actor completed scenario", "actor scored 85%") отправляется как Statement на LRS (Learning Record Store). Реализуем через TinCan.NET или собственный REST-клиент к LRS endpoint.

Этапы работы

Анализ требований. Роли, сценарии входа, интеграции, требования к безопасности хранения данных.

Выбор схемы авторизации. Определяем метод входа под целевые устройства и сценарии использования.

Разработка Permission Layer. IPermissionService, RBAC-модель, интеграция с игровой логикой.

Бэкенд-интеграция. Настройка auth endpoint, JWT, refresh flow, или интеграция с готовым IdP (Auth0, Azure AD B2C, Keycloak).

Тестирование. Проверка всех ролей, сценарии истёкшего токена, тест смены пользователя, penetration-тест на предмет обхода permission checks.

Стоимость рассчитывается индивидуально после анализа требований к безопасности и интеграциям.