Как протестировать протокол подтверждения адреса электронной почты с помощью эксперимента с источником

Опубликовано 8 июля 2026 г. Последнее обновление: 5 октября 2026 г.

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

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

Демоверсия запроса пользователя в Email Verification API
Демоверсия запроса пользователя в Email Verification API

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

Вы можете попробовать этот процесс с демоаккаунтом:

Процедура подтверждения адреса электронной почты

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

Основные понятия

Ниже приведены основные термины, связанные с Email Verification API.

  • Проверяющая сторона. Сайт, который собирает адреса электронной почты и хочет их подтвердить. Проверяющая сторона также называется доверяющей стороной.
  • Поставщик услуг электронной почты – сервис, предоставляющий адрес электронной почты пользователя, например gmail.com.
  • Издатель – сервис, управляющий аккаунтом электронной почты пользователя, например accounts.google.com. Эмитент также называется поставщиком идентификационной информации.

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

Архитектура процесса подтверждения адреса электронной почты
Архитектура процесса подтверждения адреса электронной почты

Требования

  • Пользователь должен войти в аккаунт поставщика услуг электронной почты или эмитента в том же профиле браузера. Например, если они используют Gmail, то должны войти в аккаунт Google.
  • Как сайт, участвующий в проверке, вы должны зарегистрироваться для участия в эксперименте с источником и добавить токен на ту же страницу, что и форму для ввода адреса электронной почты.
  • Пользователь должен выбрать свой адрес электронной почты из раскрывающегося списка автозаполнения.

    • Если пользователь уже вводил адрес электронной почты в это поле, он будет предложен в качестве варианта автозаполнения.
    • Если пользователь добавил свой адрес электронной почты в настройках Chrome "Автозаполнение и пароли" (chrome://settings/autofill), он будет предлагаться при автозаполнении.

  • Когда пользователь впервые укажет адрес электронной почты для подтверждения, он увидит запрос разрешения. Это происходит только один раз для каждого адреса электронной почты.

Когда пользователь откроет активный сеанс в браузере, он сможет начать процесс:

  1. В форме с полем для адреса электронной почты пользователь выбирает свой адрес из раскрывающегося списка автозаполнения. Сайт, выполняющий проверку, предоставляет скрытое поле в форме с одноразовым кодом для проверки этого запроса.
  2. Затем браузер получит запись DNS для подтверждения адреса электронной почты домена. Это указывает браузеру на издателя. Затем эмитент подтвердит, что для этого адреса электронной почты есть активный сеанс.

  3. Затем эмитент предоставит токен подтверждения адреса электронной почты (EVT). Браузер объединяет эти данные в токен JWT, привязанный к ключу, с EVT, источником сайта и одноразовым номером из формы ввода.

  4. Когда форма отправляется, пакет EVT добавляется в скрытое поле и отправляется на сайт.

  5. Затем сайт проверяет все эти данные: ожидаемый адрес электронной почты, одноразовый код и подписи браузера и издателя.

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

В результате проверяющий сайт получает подтверждение, что адрес электронной почты действителен и принадлежит текущему пользователю. Это позволяет сайту не отправлять письмо с подтверждением.

Пользователи могут управлять подтвержденными адресами электронной почты в разделе Настройки > Автозаполнение и пароли > Контактная информация > Подтвержденный адрес электронной почты (или открыть chrome://settings/contactInfo).

Рекомендации по использованию

Подтверждение адреса электронной почты – это дополнительная функция, которая позволяет пользователям не покидать ваш сайт, чтобы получить одноразовый пароль или перейти по ссылке. Сайты могут добавить поля для подтверждения адреса электронной почты во все подходящие формы, например для входа в аккаунт, подписки на новостную рассылку, создания аккаунта и восстановления пароля. EVP срабатывает, только если браузер поддерживает его. Если код не получен после отправки или не пройдена проверка, можно вернуться к стандартному процессу подтверждения по электронной почте. Это также означает, что API не поддерживает обнаружение функций. Сайт проверяющего рассматривает EVT как необязательный параметр и обрабатывает его, если он присутствует в запросе.

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

Как реализовать сайт верификатора

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

Как настроить поля формы

Убедитесь, что поля формы имеют правильные атрибуты:

<input
  name="email-address"
  type="email"
  autocomplete="email">
<input
  type="hidden"
  name="token"
  nonce="rAnD0m-VaLuE"
  autocomplete="email-verification-token">

Задайте для атрибутов type и autocomplete элемента email значение email, чтобы браузер мог предлагать автозаполнение для адреса электронной почты.

Новое поле hidden будет заполнено токеном подтверждения адреса электронной почты после отправки формы. Необходимые атрибуты:

  • Установите значение type="hidden", поскольку это поле не требует ввода данных пользователем.
  • Задайте значение nonce="rAnD0m-VaLuE". Сайт должен предоставлять уникальный одноразовый код, связанный с сеансом, чтобы подтвердить отправку формы.
  • Задайте значение autocomplete="email-verification-token". Браузер использует этот атрибут, чтобы определить, какое поле нужно заполнить.

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

Как проверить EVT

Проверка каждого компонента пакета EVT состоит из пяти этапов.

  1. Проанализируйте токен.
  2. Проверьте ожидаемые значения.
  3. Проверьте привязку ключа.
  4. Проверьте запись DNS.
  5. определить издателя и проверить подпись EVT.

1. Как анализировать токен

Необработанные данные из отправленной формы содержат EVT и подписанные утверждения в JSON Web Token с выборочным раскрытием (SD-JWT+KB), разделенные тильдой (~). Вам нужно будет разделить их и декодировать заголовки и полезные нагрузки Javascript Object Signing and Encryption (JOSE), например с помощью jose для Node.js.

Если example.com подтверждает demo@gmail.com, декодированная полезная нагрузка будет выглядеть примерно так, как показано в примере ниже.

{
  "evtJwtDecodedPayload": {
    "cnf": {
      "jwk": {
        "crv": "Ed25519",
        "kty": "OKP",
        "x": "pUbLiCkEy123pUbLiCkEy123pUbLiCkEy123"
      }
    },
    "email": "demo@gmail.com",
    "email_verified": true,
    "iat": 1782911685,
    "iss": "https://accounts.google.com"
  },
  "kbJwtDecodedPayload": {
    "aud": "https://example.com",
    "iat": 1782911685,
    "nonce": "rAnDoM123rAnDoM123rAnDoM123rAnDoM123",
    "sd_hash": "hAsH456hAsH456hAsH456hAsH456hAsH456"
  }
}

2. Проверка ожидаемых значений

Убедитесь, что основные значения в полезной нагрузке соответствуют указанным вами значениям:

  • Убедитесь, что для параметра email_verified задано значение true.
  • Убедитесь, что значение email совпадает с адресом электронной почты, указанным в форме.
  • Убедитесь, что значение nonce соответствует однократному номеру, указанному в форме.
  • Убедитесь, что значение aud соответствует источнику вашего сайта.
  • Убедитесь, что временная метка iat относительно недавняя, например после того, как была отрисована форма.

3. Проверка привязки ключа

Браузер создает временный ключ для транзакции, чтобы подтвердить, что он подписал токен. Извлеките этот ключ из утверждения cnf (confirmation) в EVT, а затем используйте его для проверки связанного с ключом токена JWT.

Затем рассчитайте ожидаемый хеш и сравните его с хешем, указанным в заявке sd_hash. Ниже приведен пример кода на Node.js, который выполняет этот расчет:

const calculatedHash = createHash("sha256")
        .update(evtJwt + "~")
        .digest("base64url");

4. Как проверить запись DNS

Проверьте запись _email-verification DNS для домена адреса электронной почты. Например, для demo@gmail.com запросите запись _email-verification.gmail.com TXT. Для этого поставщика запрос возвращает местоположение аккаунта поставщика, то есть accounts.google.com.

$ dig +short TXT _email-verification.gmail.com
"iss=accounts.google.com"

5. Как найти издателя и проверить подпись EVT

Убедитесь, что издатель предоставляет ресурс /.well-known/email-verification, в котором указаны конечные точки для выпуска токена, веб-ключ JSON (JWK) для сайта и поддерживаемые алгоритмы подписи.

$ curl https://accounts.google.com/.well-known/email-verification
{
  "issuance_endpoint": "https://accounts.google.com/gsi/email-verification/issue",
  "jwks_uri": "https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA"]
}

Используйте JWK, чтобы проверить JWT EVT, извлеченный из токена. В большинстве библиотек JOSE есть функции для выполнения этой проверки.

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

Реализуйте сервис поставщика услуг электронной почты и издателя

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

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

Как настроить обнаружение эмитента

Чтобы браузеры могли автоматически обнаруживать ваши конечные точки проверки при выборе адреса электронной почты, принадлежащего вашему домену, предоставьте доступ к конфигурации с помощью DNS и конечной точки HTTP .well-known.

Как настроить запись делегирования DNS

Настройте запись DNS TXT в домене электронной почты, которая делегирует полномочия на проверку идентификатору издателя. Эти идентификаторы могут использовать один и тот же домен, в зависимости от вашей инфраструктуры.

Формат записи: _email-verification.<email-domain>

Пример файла зоны:

_email-verification.example.com IN TXT "iss=accounts.issuer.example"

Как разместить конечную точку .well-known/email-verification

Разместите файл JSON с метаданными в домене эмитента по пути /.well-known/. В этом файле указаны ваши возможности по выпуску сертификатов и криптографические алгоритмы подписи, которые поддерживает ваша инфраструктура.

Конечная точка: https://<issuer-domain>/.well-known/email-verification

Пример ответа:

{
  "issuance_endpoint": "https://accounts.issuer.example/email-verification/issuance",
  "jwks_uri": "https://accounts.issuer.example/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA", "ES256"]
}

Как разместить конечную точку .well-known/web-identity

Дополнительный ресурс JSON .well-known, который вы, возможно, уже реализовали как часть Federated Credentials (FedCM) API. Здесь можно найти ссылки на конечную точку аккаунта и URL для входа.

Конечная точка: https://<domain>/.well-known/web-identity

Пример ответа:

{
  "accounts_endpoint": "https://accounts.issuer.example/accounts",
  "login_url": "https://accounts.issuer.example/login"
}

Используйте конечную точку аккаунтов

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

Конечная точка: как указано в .well-known/web-identity.

Пример ответа:

{
  "accounts": [
    {
      "id": "demo-example",
      "name": "Demo User",
      "email": "demo@example.com",
      "given_name": "Demo"
    }
  ]
}

Как интегрировать Login Status API

У пользователя должен быть активный сеанс с поставщиком, и вы должны сообщить об этом браузеру с помощью API статуса входа.

Когда пользователь успешно входит в аккаунт или выходит из него, отправьте соответствующий заголовок HTTP-ответа:

Set-Login: logged-in
Set-Login: logged-out

Вы также можете обновить статус с помощью JavaScript в контексте веб-приложения:

navigator.login.setStatus("logged-in");
navigator.login.setStatus("logged-out");

Как обрабатывать запросы на выпуск

Ваш issuance_endpoint получает запрос application/x-www-form-urlencoded POST, содержащий request_token.

Ниже описан полный процесс обработки запросов на выпуск.

1. Проверка запроса на выпуск

Анализировать и проверять входящие полезные нагрузки браузера:

  • Метод: POST
  • Проверка сеанса. Проверьте собственные файлы cookie пользователя, переданные вместе с запросом, чтобы убедиться, что контекст активного авторизованного пользователя существует.session/authentication
  • Проверка параметров. Извлеките параметр request_token (подписанный JWT, созданный браузером). Убедитесь, что в нем есть временный открытый ключ, целевой адрес электронной почты, правильная аудитория и действительная временная метка.

Декодированный токен должен выглядеть примерно так:

{
  "decodedHeader": {
    "alg": "ES256",
    "typ": "JWT",
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "decodedPayload": {
    "iss": "https://accounts.issuer.example",
    "sub": "demo@example.com",
    "email": "demo@example.com",
    "iat": 1780272000,
    "exp": 1780272300
  },
  "signature": "SIGnatURE-123_SIGnatURE-123_SIGnatURE-123"
}

2. Как ответить с помощью токена

После успешной проверки токена сеанса и запроса сгенерируйте подписанный JWT для выборочного раскрытия информации (SD-JWT), используя следующие данные:

{
  "iss": "https://accounts.issuer.example",
  "iat": 1780272000,
  "exp": 1780272300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "email": "demo@example.com",
  "email_verified": true
}

Подпишите полезную нагрузку с помощью закрытого ключа и поддерживаемого алгоритма. Например, с помощью jose в Node.js:

const evtJwt = await new SignJWT(evtPayload)
   .setProtectedHeader({
     alg: "EdDSA",
     kid: PRIVATE_KEY_JWK.kid, // Key ID corresponding to our JWKS keys
     typ: "evt+jwt", // Standard Token Type for EVTs
   })
   .sign(privateKey);

 // Standard SD-JWT compatibility requires appending a trailing tilde "~"
 // to separate the signed token from the key binding section.
 const issuanceToken = `${evtJwt}~`;

Пример успешного ответа (HTTP 200):

{
  "issuance_token": "tOkEn123tOkEn123tOkEn123...~"
}

Особенности экспериментов с источником

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

Если вы обнаружите ошибки в реализации Chrome, сообщите о них, указав следующий компонент:

Включение функции эксперимента с источником контролируется на уровне ответов путем добавления токена эксперимента с источником. Это означает, что вы можете точно настроить доступ к функции для части пользователей. Например, если у вас уже есть платформа для A/B-тестирования, вы можете интегрировать в нее пробную версию источника, чтобы контролировать выборку для эксперимента. Если у вас есть группа бета-тестирования или раннего доступа, вы можете включить для нее эту функцию. В этом случае перед выдачей или проверкой токена необходимо сравнить его с указанным адресом электронной почты.

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

Мы будем публиковать новости в этом блоге и в списке рассылки evp-announce@chromium.org по мере разработки.