Перейти к основному содержанию
Аутентификация является новой функцией: DiditAuth for iOS зависит от выпуска. Координаты дистрибуции, версии и сигнатуры вызова здесь не подтверждены. Не устанавливайте предположительно подходящий пакет и не используйте SDK верификации личности как SDK аутентификации.

​
Подготовка приложения

  1. Убедитесь, что аутентификация включена для вашего приложения Didit, и скопируйте его origin для входа (https://<slug>.auth.didit.me или <slug>.sandbox.auth.didit.me для песочницы) из консоли.
  2. Зарегистрируйте точный URL обратного вызова, который поддерживают ваше приложение и среда выполнения. Проверьте владение ссылками приложения; не предполагайте, что пользовательские URL-схемы принимаются произвольно.
  3. Разделяйте конфигурацию песочницы и продакшн-среды, включая обработку обратного вызова и сохранённые учётные данные.
  4. Выберите стабильное сопоставление пользователей до подключения верификации или мониторинга.
Для входа через размещённую страницу используйте системную сессию аутентификации. Планируйте обработку нативных пасскеев и домен доверенной стороны вместе; WebView не заменяет системный поток аутентификации.

​
Реализация размещённого потока

Откройте системную сессию браузера аутентификации по URL {origin}/sign-in. Передайте новый случайный state, PKCE-challenge S256 и зарегистрированный redirect_uri. Сохраняйте верификатор в приложении только для этой попытки. Руководство по JavaScript описывает базовый протокол; в нативном коде используйте криптографию и обработку URL средствами платформы, а не глобальные объекты браузера. При обратном вызове проверьте state, срок действия транзакции и адрес назначения обратного вызова, и только после этого обменяйте одноразовый код в token/. Используйте исходный верификатор и точный redirect URI. Отмена или закрытие браузера не означает успешного входа. Храните refresh-токены в защищённом хранилище учётных данных платформы; никогда не храните их в обычном файле настроек, в аналитике или в журналах сбоев. Проверяйте текущую сессию запросом GET session/ с Bearer-токеном конечного пользователя. Обновление токенов выполняйте последовательно, заменяя оба токена одновременно, и очищайте данные, относящиеся к конкретному пользователю, после выхода. Контракт запросов и поведение при повторном использовании refresh-токена описаны в токенах и JWKS.

​
Предварительный просмотр нативного SDK

Нативные модули аутентификации планируется выпустить с функциями входа, доступа к текущей сессии, получения токенов, выхода и пошаговой аутентификации, с автоматическими сигналами устройства. Нативные пасскеи и защищённое хранение токенов входят в этот выпуск. Обёртки API будут следовать опубликованным контрактам платформ; не копируйте предполагаемые аргументы конструкторов или сигнатуры методов из примера дизайна. До выпуска модуля держите его адаптер отключённым или используйте проверенную реализацию размещённого протокола для вашего приложения с включённой аутентификацией. Не рекламируйте рабочее нативное руководство по аутентификации, основанное только на установке пакета.

​
Подключение верификации и мониторинга

Ваш бэкенд формирует vendor_data на основе аутентифицированного пользователя. Он создаёт сессии верификации или выпускает токены мониторинга с ограниченной областью действия для этого пользователя. В приложение возвращайте только учётные данные сессии или ограниченный токен; API-ключ остаётся на сервере. Используйте iOS SDK верификации, когда нужна Верификация личности. Для поддержки мониторинга на вашей платформе следуйте инструкциям по отправке транзакций через SDK. Решения по входу, верификации и транзакциям принимайте отдельно друг от друга.

​
Проверка интеграции

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