Налаштування системи рівнів доступу та авторизації у VR іграх

id: 230 slug: vr-game-access-level-and-authorization-system title_ua: "Налаштування системи рівнів доступу та авторизації у 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 гарнітури. Реалізується через ZXing .NET або ML Kit, працює на AR Foundation + Passthrough.
• PIN-код на віртуальній панелі: 4–6 цифр через XRGrabInteractable кнопки — працює на будь-якому OpenXR-пристрої.
• SSO через спарену програму: мобільна програма-компаньйон аутентифікує користувача, передає токен у 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)
• можливість переглядати сеанси інших користувачів
• право на скидання прогресу
• доступ до аналітики реального часу

Дані ролей зберігаються на backend. VR-клієнт отримує JWT токен під час авторизації, декодує claims (role, allowed_modules[], organization_id) та будує локальний кеш дозволів. Усі перевірки — через єдиний IPermissionService, не розкидані if (isAdmin) по коду.

Для зберігання сеансового токена на пристрої: PlayerPrefs не підходить — дані можуть бути прочитані без root на деяких пристроях. Використовуємо UnityEngine.Windows.File на ПК або вбудований Android KeyStore через Java плагін для Quest. Токени з exp claim мають короткий час життя (8 годин), оновлення через мовчазний фоновий запит.

Багатокористувацькі сеанси (одна Quest, кілька профілів) — окрема задача. Без вбудованого перемикання користувачів в ОС реалізуємо через власний екран змін користувача: вибір аватара + 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-модель, інтеграція з ігровою логікою.

Backend-інтеграція. Налаштування auth endpoint, JWT, refresh flow, або інтеграція з готовим IdP (Auth0, Azure AD B2C, Keycloak).

Тестування. Перевірка всіх ролей, сценарії застарілого токена, тест змін користувача, penetration-тест на можливість обходу перевірок дозволів.

Вартість розраховується індивідуально після аналізу вимог безпеки та інтеграцій.