Перейти к основному содержанию
Аутентификация является новой функцией: используйте этот пример входа через размещённую страницу в приложении, для которого включена аутентификация. Пакет @didit-protocol/auth ещё не опубликован, а API пакета ниже является предварительной версией, а не устанавливаемым примером быстрого старта.

Настройка входа через размещённую страницу

Зарегистрируйте точный URL обратного вызова (callback URL) и origin веб-приложения для вашего приложения в песочнице. Скопируйте его origin для входа (https://<slug>.sandbox.auth.didit.me) из консоли, как описано в обзоре. В этом примере используются криптографические API браузера, которым требуется HTTPS или localhost в песочнице: что именно регистрировать, см. в разделе локальная разработка. Приложение отвечает за state и PKCE-верификатор. Вход через размещённую страницу отвечает за экраны пароля, email, passkey, телефона, SSO и обязательного MFA. В этом коде не должно быть API-ключа.
auth.js
Вызовите signIn() из кнопки входа. На зарегистрированной странице обратного вызова один раз вызовите handleCallback(), отобразите состояние загрузки и покажите ошибку, если вызов завершился неудачей. Для текущего пользователя используйте getSession(), а для выхода из системы signOut(). Страница обратного вызова удаляет свой код из адресной строки до отправки запроса. Этот минимальный пример хранит токены в памяти и снова выполняет вход после перезагрузки страницы или истечения срока действия токена доступа. Для постоянных сессий используйте свой бэкенд с защищёнными cookie или реализуйте сериализованную ротацию refresh-токенов. Никогда не помещайте refresh-токены в URL или логи. Проверка сессии на фронтенде влияет только на отображение; ваш бэкенд должен проверять вызывающего пользователя при каждом защищённом запросе.

Предварительная версия SDK аутентификации

Планируемое ядро @didit-protocol/auth будет предоставлять createDiditAuth({publishableKey}), signIn(), handleRedirectCallback(), getSession(), getToken(), onAuthStateChange и signOut(), а также vendorData в объекте идентификации. Предполагается, что оно добавит автоматические сигналы устройства и серверную точку входа с verifyToken(). Публикуемый ключ (publishable key) имеет вид pk_live_ (для рабочего приложения) или pk_test_ (для приложения в песочнице), за которым следует base64url-кодирование origin вашего приложения без символов заполнения. SDK отправляет свои API-вызовы на этот origin. Ключ является публичным: он идентифицирует приложение и не является секретом.

Step-up и повторная аутентификация в предварительной версии

  • stepUp({ action, amount?, currency?, redirectUri? }) вызывает POST step-up/ вашего приложения, чтобы узнать, требует ли action проверки личности. action может быть payout, bank или contact, а для выплаты нужен amount. Если применяется одно из ваших правил step-up, пользователь перенаправляется на страницу верификации, которую вернул Didit.
  • handleStepUpCallback(url?) выполняется на странице, на которую возвращается пользователь. Он читает ?step_up=<id>, удаляет его из адресной строки и получает результат через GET step-up/{id}/.
  • reauthenticate({ method? }) повторно выполняет вход того же пользователя на размещённой странице (method: "redirect", по умолчанию) или с помощью passkey (method: "passkey", только на домене входа Didit вашего приложения). После размещённой страницы завершите вход через handleRedirectCallback(). Если вход завершит другой человек, метод завершится ошибкой step_up_user_mismatch, а исходная сессия сохранится.
Оба метода step-up возвращают { id, status, approved, rule, method }, где status может быть not_required, pending, approved, review, declined или expired. redirectUri по умолчанию равен адресу перенаправления клиента и должен точно совпадать с одним из зарегистрированных адресов перенаправления вашего приложения: если требуется проверка, Didit отклоняет любой другой адрес. Прежде чем ваш бэкенд применит результат step-up, повторно запросите результат через GET step-up/{id}/ с токеном доступа пользователя, поскольку результат, переданный браузером, может быть изменён. Headless-вход также может вернуть protection_required, если правила защиты вашего приложения его пометили. Тогда пользователь завершает вход кодом, который Didit отправил ему по электронной почте (protection.verify({ code })), или с помощью passkey (protection.passkey()). Поле methods перечисляет, какими из этих двух способов он может воспользоваться. Не устанавливайте предполагаемую версию и не пишите код по предполагаемым параметрам обратного вызова. Прежде чем заменять пример с размещённой страницей, подтвердите экспорты опубликованного пакета, настройки издателя и конфигурацию ключей. Пароль, код из электронного письма, магическая ссылка, passkey, телефон, MFA, вход через социальные сети, step-up и методы агентов будут зависеть от API, поддерживаемого в этом релизе.

Добавление других продуктов

Ваш бэкенд проверяет токен доступа (см. токены и JWKS) и читает его vendor_data. Используйте это значение как vendor_data при создании сессии верификации или выпуске токена транзакции. Успешный вход не означает, что какой-либо из этих продуктов одобрил пользователя. Перед запуском проверьте на включённом приложении в песочнице регистрацию, повторный вход, отмену, несовпадение state, повторное использование кода, восстановление пароля, MFA, истечение срока действия и выход из системы.
Последнее изменение 7 ноября 2026 г.