Перейти к основному содержанию
Didit предоставляет сервер авторизации OpenID Connect, созданный специально для делегированной верификации личности. Он реализует контракт, который ожидает фреймворк Okta «bring your own identity verification vendor» (BYO IDV): Pushed Authorization Requests (PAR, RFC 9126), поток авторизационного кода с PKCE и ID-токен, содержащий объект OpenID Connect verified_claims. Одни и те же эндпоинты работают для любой доверяющей стороны, которая поддерживает этот профиль, включая Auth0 post-login Actions.

Эндпоинты

Все эндпоинты находятся под базовым URL моста верификации личности. Продакшн и песочница используют одни и те же эндпоинты. Среду определяет приложение, связанное с вашими учётными данными клиента. Для каждой среды используйте отдельные учётные данные клиента и сценарий, принадлежащий соответствующему приложению. Симулированные результаты верификации описаны в разделе Песочница и тестовые данные. Документ discovery по адресу {base}/.well-known/openid-configuration содержит все эндпоинты: Аутентификация клиента выполняется через client_secret_basic или client_secret_post. Поток авторизационного кода требует PKCE с code_challenge_method=S256. ID-токены подписываются алгоритмом RS256; проверяйте их по эндпоинту JWKS.

Поток

  1. Доверяющая сторона отправляет запрос авторизации на POST /par. Запрос включает PKCE-челлендж, state, nonce, зарегистрированный redirect_uri, области openid profile identity_assurance и утверждения, которые нужно верифицировать. Didit возвращает одноразовый request_uri, который действителен 60 секунд.
  2. Доверяющая сторона перенаправляет браузер пользователя на GET /authorize?request_uri=.... Didit создаёт сессию верификации и направляет пользователя в размещённый процесс верификации.
  3. Когда пользователь завершает процесс, Didit оценивает решение по верификации, сравнивает извлечённые данные личности с утверждениями, которые были переданы, и возвращает пользователя на redirect_uri доверяющей стороны с одноразовым code и исходным state.
  4. Доверяющая сторона обменивает код на POST /token, передавая свой code_verifier, и получает подписанный ID-токен.

Запрос утверждений

Передайте утверждения для сравнения в стандартном параметре claims OpenID Connect в PAR-запросе. Поддерживаются given_name и family_name, и оба всегда сравниваются нечётко. verified_claims является массивом, как в профиле BYO IDV Okta и в ответе с ID-токеном ниже.

ID-токен

ID-токен содержит массив verified_claims. assurance_level равен VERIFIED только тогда, когда сессия верификации одобрена и все запрошенные утверждения совпали с верифицированным документом. В противном случае он равен FAILED.
verification_process содержит идентификатор сессии Didit, поэтому вы можете найти верификацию в консоли или через API сессий.
Считайте пользователя верифицированным только тогда, когда trust_framework равен IDV-DELEGATED и assurance_level равен VERIFIED. Любая другая комбинация означает, что верификация не прошла.

Настройка Okta

Попросите Didit включить верификацию личности для ваших продакшн-приложений и приложений в песочнице, связать каждое приложение с его сценарием верификации и зарегистрировать точный URL обратного вызова для каждого тенанта Okta. Одного существующего приложения или API-ключа недостаточно для включения этой интеграции. В Okta Admin Console добавьте специального поставщика верификации личности и заполните значения из таблицы ниже. Okta создаёт интеграцию как поставщика идентификации типа IDV_STANDARD с протоколом ID_PROOFING, после чего укажите его в правиле Account Management Policy. Настройте продакшн и песочницу как две отдельные интеграции верификации личности с соответствующими учётными данными. Для обеих используйте указанные выше эндпоинты. Секрет клиента обязателен, даже несмотря на то, что поток также использует PKCE. Отдельно созданный именованный API-ключ не может заменить основной API-ключ приложения в этой интеграции. Передайте Didit свой URL обратного вызова, чтобы он был зарегистрирован для вашего клиента. Okta формирует его как {yourOktaOrgUrl}/idp/identity-verification/callback.

Настройка Auth0

У Auth0 нет встроенного слота для поставщика IDV, поэтому верификация запускается из post-login Action, который перенаправляет пользователя в тот же поток. Сохраните DIDIT_IDV_BASE, DIDIT_CLIENT_ID и DIDIT_CLIENT_SECRET как секреты Action, а https://{yourAuth0Domain}/continue зарегистрируйте в Didit как redirect URI.
Auth0 добавляет собственный state к перенаправлению на /authorize, чтобы продолжить вход. Didit использует этот state и возвращает его в /continue, и именно это позволяет Auth0 завершить транзакцию. Передавать state Auth0 в теле PAR-запроса не нужно, так как он не генерируется до перенаправления.
Сохраняйте PKCE code_verifier для каждой транзакции входа (ключом служит event.transaction.id), а не в одном поле app_metadata. Если пользователь повторяет попытку или запускает параллельный процесс входа, общее поле перезаписывается, и обмен токена завершается ошибкой invalid_grant.

Ошибки

Ошибки соответствуют RFC 6749 и RFC 9126. При неудачной аутентификации клиента возвращается 401 с {"error": "invalid_client"}. Если request_uri или код авторизации истёк или был использован повторно, возвращается 400 с invalid_request или invalid_grant. Коды авторизации, значения request_uri и сессии верификации одноразовые.
Последнее изменение 7 ноября 2026 г.