Для создания нового профиля устройства приложения должны вызвать функцию enrollUser;см. https://api.ionic.com/jssdk/latest/Docs/tutorial-device_enrollment.html
Из документов
При успешной аутентификации в течение 10-минутного интервала ожидания профиль регистрации хранится в зашифрованном виде в localStorage под appId, userId иПроисхождение вызывающего приложения.
Таким образом, профиль хранится в зашифрованном виде.Профили также хранятся как вложенные и имеют пространство имен по origin, appid и userId, как показано ниже (см. Функцию queryProfiles в ProfileManager.js):
profile [origin][appId] [userId]
Обратите внимание, что информация origin берется из объекта события postMessage, полученного кодом ядра sdk, работающим внутри iframe.
The loadUser функция принимает те же параметры, что и enrollUser, и выполняет обратную операцию, загружая профиль из localStorage и расшифровывая его.
Итак, в итоге
Что мешает загружать код SDK JS (и последующий iframe) на вредоносный сайт и использовать его для доступа к профилям, которые пользователь создал для шифрования / дешифрования данных?
Приложение должно иметь доступ кте же appId, userId и userAuth значения и будут работать на одном и том же origin для получения доступа к профилю, созданному другим приложением.
На практике
appId жестко запрограммирован для данного приложенияПликации (т.е. в js / html) userId и userAuth хранятся в объекте сеанса пользователя приложения.Эти значения могут быть либо получены с помощью ajax-запроса на исходный сервер приложения, либо записаны в html приложения.Это похоже на обычные методы обработки для токенов CSRF .