Перейти к основному содержанию
Authentication является новым. Сначала выполните каждый импорт в песочнице приложения, а затем импортируйте данные в продакшн-приложение.
Импорт переносит пользователей из другой платформы идентификации в Didit Authentication. Вместе с ними переходят их пароль, подтверждённый email, ссылки на вход через соцсети, приложение-аутентификатор и роли в организациях. Для пользователей ничего не меняется, пока ваше приложение не выполнит вход через Didit. Импорты выполняются через API управления Authentication вашего приложения с сессией в консоли, которая имеет разрешение write:authentication (или read:authentication, чтобы получать список импортов). Они никогда не используют токен конечного пользователя или API-ключ верификации. В примерах MANAGEMENT_BASE выглядит так:

Два способа импорта

Импорт файла

1. Загрузка

Каждый переключатель keep_* имеет значение true, если вы не передали false. Вызов возвращает 202 и задачу. В одном приложении одновременно может храниться не более 5 загруженных файлов.

2. Проверка пробного прогона

Каждая загрузка начинается с пробного прогона. Он проверяет каждого пользователя и ничего не записывает. Опрашивайте GET import-jobs/{id}/: Если пробный прогон завершился с ошибкой, в ответе перечислены ошибки. Исправьте файл и загрузите его заново.

3. Запуск импорта

POST import-jobs/{id}/start/ импортирует данные, которые прошли пробный прогон, и возвращает 202.
  • Пользователи импортируются пакетами по 1 000. Каждый пакет фиксируется отдельно.
  • В одном приложении одновременно выполняется только один импорт (иначе возвращается import_running).
  • Прерванный импорт продолжается после последнего зафиксированного пакета.
  • Пользователи, которые уже импортированы, пропускаются, поэтому один и тот же файл можно запустить повторно.
  • Тот, кто запустил импорт, получит письмо по его завершении или остановке.
Загруженный файл хранится в зашифрованном виде. Он удаляется по завершении импорта, при сбое пробного прогона или через 24 часа после пробного прогона, если файл так и не был импортирован.

Пакетный импорт

Отправляйте до 1 000 пользователей в одном запросе с idempotency_key длиной до 100 символов.
  • Пробный прогон возвращает 200 с результатом и ничего не записывает.
  • При dry_run: false успешный импорт возвращает 201. Если в пакете есть хотя бы одна ошибка, возвращается 400, и ни один пользователь не импортируется.
  • Повторный запрос с уже зафиксированным ключом возвращает сохранённый результат. Тот же ключ с другим содержимым возвращает 400 {"idempotency_key": "different_payload"}.
  • Параметры Firebase передаются в объекте firebase: {signer_key, salt_separator, rounds, mem_cost}.
  • GET imports/ показывает список зафиксированных пакетов.

Формат файла

JSON

Массив пользователей или объект, в поле users которого находится массив.

CSV

Те же столбцы, содержащие одно значение, а также google_id, apple_id, github_id, microsoft_id, microsoft_tenant_id, organization_slug, organization_name и organization_role. Для пользователя, состоящего в нескольких организациях, указывается отдельная строка для каждой организации.
Неизвестные поля или столбцы считаются ошибками и никогда не пропускаются.

Дубликаты и существующие аккаунты

  • Строки с одинаковым email становятся одним пользователем. Полностью совпадающая строка учитывается как дубликат. Строка с большим количеством ссылок, организаций или приложением-аутентификатором объединяется.
  • Два разных хеша пароля, секрета аутентификатора или роли в организации у одного пользователя считаются ошибками. Ошибкой также считается external_id или идентификатор субъекта провайдера, указанный двумя разными пользователями.
  • Если аккаунт с таким email уже существует и его создал предыдущий импорт, пользователь пропускается (already_imported). Если пользователь зарегистрировался самостоятельно, возникает ошибка identity_conflict. Импорт никогда не изменяет существующий аккаунт.

Пароли

Параметры Firebase хранятся в зашифрованном виде и только для этого приложения. Любой другой формат или параметр стоимости выше этих пределов означает, что человеку нужно задать новый пароль. После первого успешного входа Didit сохраняет пароль человека заново в своём формате.

Люди без пригодного пароля

Если у человека нет хеша или хеш не поддерживается, попытка входа с паролем получает обычный ответ о неверном пароле. Didit также отправляет ему на email ссылку для установки нового пароля (действует 30 минут, не чаще одного раза в день). Это происходит только в том случае, если его email подтверждён, аккаунт не заблокирован и вход по паролю включён. В результате reset_required считает людей без пригодного пароля. reset_emails считает среди них тех, у кого email подтверждён: только до них можно дотянуться таким способом. Люди с неподтверждённым email не могут войти по паролю. Они по-прежнему могут войти по коду из email, если вы включите этот способ.

Социальные связи, аутентификаторы и организации

  • Социальные связи сохраняются для провайдеров, которые ваше приложение уже настроило, с его текущим идентификатором клиента. Повторный вход в этом случае не требует подтверждения по email. Идентификаторы (subject) Google и GitHub глобальны. Идентификаторы Apple привязаны к команде разработчиков, а идентификаторы Microsoft к регистрации приложения, поэтому такие связи совпадают только в том случае, если ваша старая платформа использовала ту же команду или ту же регистрацию. Связи с провайдерами, которых вы не настроили, учитываются как social_unavailable и не импортируются.
  • Приложения-аутентификаторы (секреты TOTP: SHA-1, 6 цифр, 30 секунд) хранятся в зашифрованном виде. Импортированные люди должны использовать их как второй фактор. Коды восстановления для них не создаются.
  • Организации, которых ещё нет, создаются по их слагу.
  • Ключи доступа импортировать нельзя. Они привязаны к домену, использовавшемуся для старого входа, поэтому люди добавляют новый ключ доступа после входа через Didit.

Результаты

Каждый пробный запуск, пакет и задача возвращает один и тот же result: Ответы никогда не содержат хешей паролей, солей, секретов аутентификаторов или значений полей.

Перед переключением

Проверьте в своём приложении в песочнице:
  • вход с каждым импортируемым форматом пароля,
  • письмо со ссылкой для установки нового пароля для человека без пригодного хеша,
  • вход через соцсети и коды аутентификатора для импортированных людей,
  • повторный запуск того же файла.
Затем убедитесь, что vendor_data каждого человека совпадает со значением, которое вы используете для его верификаций и транзакций.
Последнее изменение 7 ноября 2026 г.