Биометрическая ступенчатая аутентификация для доступа к API ИИ: Привязка привилегий к человеку (RU)

Верификация при регистрации подтверждает, кто создал аккаунт. Она ничего не говорит о том, кто использует его сейчас.

Этот пробел обычен для большинства продуктов и критичен для платформы ИИ, где активы, стоящие за аккаунтом, — это доступ к моделям, кредиты и квоты. Ключ API является токеном предъявителя — тот, кто им владеет, является аккаунтом. Ключи передаются внутри команд, вставляются в репозитории, продаются и захватываются. Через шесть месяцев после успешной регистрации «этот аккаунт был верифицирован» — это утверждение о прошлом.

Биометрическая аутентификация устраняет этот пробел. Она повторно верифицирует реального человека в момент выполнения привилегированного действия — без документов, без пароля, менее чем за две секунды, $0.10 за аутентификацию.

Основные выводы

• Верификация при регистрации — это снимок. Биометрическая аутентификация — это проверка в момент, когда это важно.
• Проверка живости плюс сравнение лица с портретом, уже сохраненным после первоначальной верификации пользователя. Без документов, без пароля.
• Только для сессии. Нет конечной точки /v3/biometric-auth/ — она работает через сессию с workflow_type=BIOMETRIC_AUTHENTICATION.
• Критическая деталь реализации: используйте тот же vendor_data, что и при первоначальной верификации пользователя, иначе сохраненное лицо не может быть извлечено.
• Правильные триггеры: увеличение квот, предоставление кредитов, выдача нового ключа API, обновление тарифов, добавление привилегированных членов команды и любые поведенческие оповещения от вашего сетевого уровня.
• $0.10 за аутентификацию, оплата по факту успеха, менее двух секунд.

Почему повторная аутентификация необходима на платформе ИИ

Три сценария сбоя делают снимок при регистрации недостаточным.

Передача и перепродажа ключей. Ключ, выданный верифицированному разработчику, может оказаться где угодно. Аккаунт остается верифицированным; человек, использующий его, не является тем, кто прошел верификацию. Это механизм, посредством которого легитимно верифицированный аккаунт становится точкой входа в фермерскую сеть — и это невидимо для любого контроля, который смотрит только на регистрацию.

Захват аккаунта. Учетные данные фишингуются или подбираются, и злоумышленник наследует верифицированный аккаунт с установленной репутацией и повышенными лимитами. Верифицированный аккаунт является более привлекательной целью для захвата, а не менее.

Эскалация постфактум. Аккаунт, верифицированный для скромного доступа в январе, запрашивает 50-кратное увеличение квоты в августе. Ничто в январской верификации не относится к августовскому запросу.

Во всех трех случаях статус верификации аккаунта не меняется, а человек, стоящий за ним, не тот, кого вы думаете. Пароль, одноразовый код или токен сессии не могут различить эти случаи, потому что каждый из них — это злоумышленник, который легитимно владеет учетными данными. Только биометрическая проверка задает важный вопрос: является ли человек, находящийся здесь прямо сейчас, тем, кто прошел верификацию?

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

Биометрическая аутентификация повторно использует те же компоненты LivenessV3 и FaceMatchV3, что и обычный процесс идентификации. Единственное отличие заключается в том, откуда берется эталонное изображение — вместо портрета на только что отправленном документе, она использует портрет, уже сохраненный после предыдущей верификации пользователя.

Именно поэтому ей не нужны документы, и именно поэтому она достаточно быстрая и дешевая, чтобы вписаться в обычный рабочий процесс.

Только для сессии

Нет выделенной конечной точки /v3/biometric-auth/. Аутентификация осуществляется через сессию, рабочий процесс которой настроен для этого — workflow_type=BIOMETRIC_AUTHENTICATION. Если вы ищете отдельную конечную точку в справочнике API, то именно поэтому вы не можете ее найти.

Рабочий процесс

1. Настройте рабочий процесс типа BIOMETRIC_AUTHENTICATION в консоли и запишите его workflow_id.
2. Создайте сессию:

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

1. Отправьте пользователя через возвращенную сессию — размещенную или встроенную с помощью любого из бесплатных SDK.
2. Получите решение:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Или подпишитесь на session.status.updated и используйте вебхук.

Единственная деталь, которая ломает интеграции

Используйте тот же vendor_data, что и при первоначальной верификации пользователя.

Это значение используется Didit для извлечения сохраненного портрета для сравнения. Новый или другой vendor_data означает отсутствие сохраненного лица для сравнения, и поток не сможет выполнить то, что вы запросили. Если вам нужно намеренно переопределить сохраненную ссылку, передайте portrait_image явно — но обычный путь — это стабильный vendor_data для каждой учетной записи, установленный при регистрации и используемый всегда.

Это аргумент в пользу того, чтобы с самого начала рассматривать vendor_data как первоклассный идентификатор в вашей собственной схеме. Это также то, что позволяет чисто сопоставлять результаты Face Search с вашими учетными записями.

Чтение результата

Результаты приходят в liveness_checks и face_matches. Оба всегда являются массивами — никогда не отдельными объектами — и каждый элемент содержит node_id, чтобы многоэкземплярные рабочие процессы могли различать шаги. Каждый из них null, пока его шаг не сгенерировал данные.

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

Что должно вызывать ступенчатую аутентификацию

Ценность этого контроля почти полностью зависит от дизайна триггеров. Слишком много — и вы создали неудобство; слишком мало — и он никогда не сработает, когда это важно.

Эскалация доступа — увеличение квот, предоставление кредитов, выдача нового ключа API, обновление тарифов, переход на уровень возможностей, который вы считаете конфиденциальным.

Изменения учетной записи — новый привилегированный член команды, изменение владельца выставления счетов, изменение адреса для выплат, сброс пароля или MFA.

Поведенческие оповещения — самый ценный триггер. Когда ваш собственный сетевой уровень помечает учетную запись за интенсивные запросы или паттерн, похожий на дистилляцию, биометрическая ступенчатая аутентификация задает вопрос, который сетевой уровень не может: является ли верифицированный человек все еще тем, кто управляет этой учетной записью? Успешная проверка сужает интерпретацию. Отказ или отказ от проверки сам по себе является сильным сигналом.

Связывающие сигналы — сессия с DEVICE_RECOVERED_HIGH_CONFIDENCE или лицо, совпавшее с существующим верифицированным пользователем, заслуживает ступенчатой аутентификации независимо от того, что запрашивает учетная запись.

Бездействие плюс эскалация — учетная запись, бездействовавшая в течение нескольких месяцев, внезапно запрашивает значительное увеличение. Не только бездействие; а их комбинация.

Почему бы просто не требовать пароль или код?

Потому что каждый обычный фактор является учетными данными предъявителя, а модель угрозы здесь — это злоумышленник, который владеет учетными данными.

Одноразовый код отправляется на номер телефона или адрес, указанный в файле — который злоумышленник контролирует после захвата, и который законный держатель ключа просто пересылает. Пароль доказывает знание строки. Аппаратный ключ доказывает владение объектом, который можно передать вместе с ключом.

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

Стоит также отметить, что он не делает. Повторная аутентификация человека, стоящего за учетной записью, не предотвращает извлечение модели и не обнаруживает его. Верифицированный разработчик все еще может злоупотреблять имеющимся доступом. Это устраняет разрыв между «эта учетная запись была верифицирована однажды» и «этот человек здесь сейчас» — узкий, реальный разрыв. Контроль вывода на уровне модели и семантическое обнаружение трафика остаются отдельными уровнями, и они остаются вашими.

Сценарии использования

Платформы API ИИ, ограничивающие эскалацию квот, предоставление кредитов и выдачу ключей проверкой человека.

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

Финансовые услуги, повторно аутентифицирующие перед высокоценным переводом или изменением адреса для выплат.

Торговые площадки, повторно верифицирующие продавца перед изменением метода выплаты — наиболее распространенный способ получения выгоды от захвата учетной записи.

Любая платформа с процессом восстановления, использующая биометрическую реаутентификацию вместо вопросов, основанных на знаниях, которые являются самым слабым звеном в большинстве систем безопасности учетных записей.

Часто задаваемые вопросы

Нужно ли пользователю снова предоставлять документ?

Нет. В этом и заключается суть. Проверка выполняется по портрету, уже сохраненному после их первоначальной верификации — проверка живости плюс сравнение лица, без документов.

Что, если пользователь никогда не был верифицирован с помощью Didit?

Тогда нет сохраненного портрета, и не с чем аутентифицировать. Биометрическая аутентификация — это примитив повторной верификации; она предполагает более раннюю верификацию с тем же vendor_data.

Сколько времени это занимает?

Менее двух секунд. С точки зрения пользователя, это селфи и мгновение.

Может ли это работать в нашем собственном интерфейсе?

Да. SDK для веб, iOS, Android, React Native и Flutter бесплатны, а White Label ($0.20) удаляет брендинг Didit.

Что, если кто-то держит фотографию или видео владельца аккаунта?

Для этого предназначена функция обнаружения живости. Пассивная проверка живости Didit имеет оценку обнаружения атак презентации iBeta Level 1, а оповещения об атаках на лицо отображаются в предупреждениях. Пороги настраиваются.

Сколько это стоит?

$0.10 за аутентификацию, оплата по факту успеха, без минимума.

Должен ли каждый вход требовать этого?

Нет. Вход в систему — это неправильный триггер — он срабатывает постоянно и в основном ни на что. Привяжите его к эскалации привилегий и к оповещениям, где цена ошибки высока, а частота низка.

Готовы начать?

Настройте один рабочий процесс, подключите его к точкам эскалации и используйте его повсюду.

• Прочитайте документацию — Обзор биометрической аутентификации и API сессий.
• Посмотрите продукт — Верификация пользователя.
• Проверьте цены — $0.10 за аутентификацию, оплата по факту успеха, без минимумов.
• Начните бесплатно — business.didit.me, 500 KYC проверок в месяц бесплатно.