Access Level and Authorization System Setup in VR Games

id: 230 slug: vr-game-access-level-and-authorization-system title_en: "VR Game Access Level and Authorization System Setup" tags: [vr-ar]

VR Game Access Level and Authorization System Setup

In corporate VR-trainers and educational platforms, authorization is not optional. Trainees should not see colleagues' results. Instructors must see everyone. Administrators should manage content. Yet all this access control must work without a keyboard: in VR there is no native way to enter a password without removing the headset.

VR Authorization Specifics

The main limitation is credential input. Standard login/password in VR is impossible without a virtual keyboard. Quest.VirtualKeyboard (OpenXR Keyboard Extension XR_META_virtual_keyboard) solves this on Meta devices, but it is Meta's native keyboard — absent on Pico or SteamVR. Alternative approaches:

• QR-authentication: user scans QR-code from phone or monitor through HMD passthrough camera. Implemented via ZXing .NET or ML Kit, works on AR Foundation + Passthrough.
• PIN-code on virtual panel: 4–6 digits via XRGrabInteractable buttons — works on any OpenXR-device.
• SSO via paired application: companion mobile app authenticates user, transmits token to VR-app via local network or deeplink (for Quest via adb shell am start).
• Proximity card / NFC: for stationary VR-stands — USB-HID reader, processed via Input.GetJoystickNames() or native plugin.

Access Level Architecture

For corporate VR-platforms we build RBAC (Role-Based Access Control) with roles: Learner, Instructor, Admin, Guest. Each role defines:

• accessible scenes/modules (via ScenePermission ScriptableObject)
• ability to view others' sessions
• permission to reset progress
• access to real-time analytics

Role data stored on backend. VR-client receives JWT token on authorization, decodes claims (role, allowed_modules[], organization_id), builds local permission cache. All checks — via single IPermissionService, not scattered if (isAdmin) across codebase.

For session token storage on device: PlayerPrefs unsuitable — data readable without root on certain devices. Use UnityEngine.Windows.File on PC or native Android KeyStore via Java plugin for Quest. Tokens with exp claim short-lived (8 hours), refresh via silent background request.

Multi-user sessions (one Quest, multiple profiles) — separate task. Without built-in OS user switching, implement via custom user switch screen: avatar selection + PIN. Profile stored in Application.persistentDataPath/profiles/{userId}/ with AES-256 encryption (key from KeyStore).

Corporate System Integration

For corporate clients, typical requirements: Active Directory / Azure AD integration (OAuth 2.0 + OpenID Connect), SSO with corporate portals, session result export to LMS (xAPI / SCORM via specialized adapters).

xAPI (Tin Can API) — VR-trainer standard: each user action ("actor completed scenario", "actor scored 85%") sent as Statement to LRS (Learning Record Store). Implemented via TinCan.NET or custom REST-client to LRS endpoint.

Work Stages

Requirements analysis. Roles, login scenarios, integrations, data storage security requirements.

Authorization scheme selection. Determine login method for target devices and usage scenarios.

Permission Layer development. IPermissionService, RBAC-model, game logic integration.

Backend integration. Auth endpoint setup, JWT, refresh flow, or ready IdP integration (Auth0, Azure AD B2C, Keycloak).

Testing. Verify all roles, expired token scenarios, user switch test, penetration test for permission check bypass.

Cost calculated individually after security and integration requirements analysis.