Аутентификация пользователей: вход, passkeys и сессии

Функция Authentication пока новая. Didit включает её для вашего приложения. До этого каждый маршрут среды выполнения этого приложения возвращает 404. Пакеты Authentication SDK ещё не опубликованы, поэтому используйте размещённый сценарий и HTTP-контракт, описанные на этих страницах.

Authentication позволяет вашим клиентам входить в ваше приложение. Это отдельный продукт: он не связан со входом в консоль Didit и созданием аккаунта разработчика Didit. Он также отличается от верификации личности. Используйте Authentication отдельно или вместе с верификацией личности и мониторингом транзакций. Вход не подтверждает верификацию и не разрешает платёж. Ваш бэкенд принимает эти решения на основе результата каждого продукта.

Как это работает

Каждое приложение получает собственный origin для входа и собственный издатель токенов. Live- и sandbox-приложения разделены: у них разные origin, настройки и идентичности.

Параметр	Значение
Origin по умолчанию	`https://<slug>.auth.didit.me` для live-приложения, `https://<slug>.sandbox.auth.didit.me` для приложения-песочницы. Консоль показывает ваш origin. Вместо него можно использовать подтверждённый собственный домен.
Размещённые страницы	`/sign-in`, `/magic`, `/invite` и `/reset` на этом origin.
API среды выполнения	Тот же origin, например `POST {origin}/token/` и `GET {origin}/session/`.
Издатель	Сам origin. Discovery доступен по адресу `{origin}/.well-known/openid-configuration`.
Публикуемый ключ	`pk_live_...` или `pk_test_...`. Он идентифицирует приложение и не является секретом.

Используется OAuth 2.0 с кодом авторизации и PKCE (только S256):

Ваше приложение открывает {origin}/sign-in с redirect_uri, state, code_challenge и code_challenge_method=S256.
Размещённая страница выполняет вход или регистрацию пользователя включёнными вами методами, включая обязательный второй фактор, если он требуется.
Браузер возвращает пользователя на ваш redirect_uri с code и state.
Ваше приложение обменивает код через POST {origin}/token/ на токен доступа, ID-токен и токен обновления.

Описание контракта токенов см. в токенах и JWKS, а о каждом методе входа см. в методах входа.

Выберите платформу

JavaScript

Размещённая страница входа, обратный вызов, сессия и выход.

React

Клиентское состояние и защищённые экраны приложения.

Next.js

Серверные сессии, маршруты обратного вызова и файлы cookie.

iOS

Системный браузер и безопасное хранение токенов.

Android

Авторизация через браузер и обратный вызов в приложении.

React Native

Подготовка нативной обёртки для аутентификации.

Flutter

Подготовка нативной обёртки для аутентификации.

Подготовьте приложение

Попросите Didit включить Authentication для вашего приложения. Сначала протестируйте в приложении-песочнице.
Зарегистрируйте точные URL перенаправления (до 50) и браузерные allowed_origins (до 50), с которых вызывается API среды выполнения.
Включите нужные методы входа. Didit ID Wallet всегда включён.
Настройте параметры сессий и паролей (см. ниже).
Перед запуском протестируйте регистрацию, вход, восстановление пароля, MFA, истечение сессии и выход.

Ключ доступа привязан к своему origin. Если позже вы подключите собственный домен, пользователям придётся заново зарегистрировать свои ключи доступа.

URL перенаправления

Didit возвращает пользователя только на адрес, который вы зарегистрировали. Зарегистрируйте его в консоли в разделе Authentication > Security and sessions > Redirect URLs and allowed origins. redirect_uri в запросе на вход должен точно совпадать с зарегистрированным URL посимвольно: схема, хост, порт, путь и параметры запроса. Другой порт, завершающий слеш или другой регистр букв означают другой адрес.

Приложение	Что можно зарегистрировать
Live	URL с `https://`
Sandbox	URL с `https://`, а также URL с `http://` на `localhost`, `127.0.0.1` или `[::1]`

Подстановочные знаки, фрагменты, учётные данные в URL и пользовательские схемы отклоняются. Если адрес не зарегистрирован, Didit никогда не перенаправляет на него. {origin}/sign-in возвращает 400 со страницей, которая объясняет, что и где нужно зарегистрировать, а POST {origin}/authorize/ возвращает 400 {"error": "invalid_redirect_uri"}.

Локальная разработка

Тестируйте на своей машине с приложением-песочницей:

Зарегистрируйте URL обратного вызова с портом, например http://localhost:3000/auth/callback.
Если код в браузере вызывает API среды выполнения, например для обмена кодом через POST {origin}/token/, добавьте origin также в Allowed origins: http://localhost:3000, без пути и завершающего слеша.
Запустите вход на origin песочницы, https://<slug>.sandbox.auth.didit.me, с вашим ключом pk_test_....

localhost, 127.0.0.1 и [::1] являются разными адресами, и каждый порт тоже считается отдельным адресом. Регистрируйте каждый адрес и порт, которые вы используете. Live-приложения никогда не принимают http://. Перед запуском зарегистрируйте ваш продакшн-URL обратного вызова с https:// в продакшн-приложении.

Настройки приложения

Вы управляете этими настройками в консоли или с помощью авторизованной сессии консоли, у которой есть право write:authentication.

Настройка	Значения	По умолчанию
`session_lifetime`	`86400`, `604800`, `2592000`, `7776000` секунд	`2592000` (30 дней)
`idle_timeout`	`1800`, `7200`, `86400`, `604800` секунд	`86400` (1 день)
`multiple_sessions`	`false` завершает остальные сессии пользователя при каждом новом входе	`true`
`password_min_length`	`8`, `10`, `12`, `14`	`10`
`revoke_on_password_change`	Завершает все сессии после сброса пароля	`true`
`signup_policy`	`anyone`, `invited`, `allowed_domains` (с `allowed_email_domains`, не более 100)	`anyone`
`allow_subaddresses`	Принимать `+` в локальной части адреса электронной почты	`false`
`post_logout_redirect_uri`	Куда ваше приложение перенаправляет пользователя после выхода	Пусто
`mfa_policy`	`optional`, `everyone`, `organization_admins`	`organization_admins`
`sign_in_ui`	`hosted` или `own`	`hosted`

Один человек в разных продуктах

У каждой личности есть значение vendor_data. Это external_id, который вы передали при импорте пользователя, или, если импорта не было, идентификатор личности Didit. Оно передается в токен доступа, ID-токен и в GET session/. Используйте то же значение как vendor_data при создании сессий верификации и отправке транзакций. Тогда события аутентификации попадут в консоли к тому же человеку, что и события его верификаций и транзакций. См. события и webhook. Формируйте vendor_data на своем бэкенде на основе проверенного токена, а не из непроверенного поля браузера.

Комбинация продуктов	Что вы создаете
Аутентификация	Вход, проверка сессий и выход.
Верификация личности + Аутентификация	Запуск верификации после входа, если это требуется вашей политикой, с `vendor_data` из токена.
Мониторинг транзакций + Аутентификация	Отправка транзакций для `vendor_data` вошедшего пользователя. События входа попадают на временную шкалу и в правила того же человека.
Все три	Один `vendor_data` на человека. Решение каждого продукта обрабатывайте отдельно.

Для любой комбинации используйте общий промпт для интеграции. Ознакомьтесь с разделом защита от ботов о политиках, которые применяются при входе.

Руководства