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.
Поток
- Доверяющая сторона отправляет запрос авторизации на
POST /par. Запрос включает PKCE-челлендж,state,nonce, зарегистрированныйredirect_uri, областиopenid profile identity_assuranceи утверждения, которые нужно верифицировать. Didit возвращает одноразовыйrequest_uri, который действителен 60 секунд. - Доверяющая сторона перенаправляет браузер пользователя на
GET /authorize?request_uri=.... Didit создаёт сессию верификации и направляет пользователя в размещённый процесс верификации. - Когда пользователь завершает процесс, Didit оценивает решение по верификации, сравнивает извлечённые данные личности с утверждениями, которые были переданы, и возвращает пользователя на
redirect_uriдоверяющей стороны с одноразовымcodeи исходнымstate. - Доверяющая сторона обменивает код на
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 и сессии верификации одноразовые.