Chrome уточнил Email Verification: Android, ключи подписи и совместимость протокола
Октябрьское обновление испытания Email Verification содержит несовместимые изменения. Браузер может подтвердить владение почтовым адресом, но сервер сайта по-прежнему обязан проверять полученный токен.
Письмо с кодом получает альтернативный маршрут
5 октября Google описала изменения Email Verification, начавшей испытание на настольном Chrome 150. С Chrome 154 в эксперимент включён Android. Для работы пользователь должен быть авторизован у своего почтового провайдера в браузере, а сайт и поставщик должны поддерживать протокол. Это не универсальное подтверждение любого введённого адреса без участия почтовой системы. В публикации говорится о подготовке выпуска, поэтому функцию нельзя обозначать окончательно доступной во всех браузерах или у всех провайдеров.
Сайт получает доказательство, а не готовую сессию входа
В руководстве для принимающей стороны форма содержит поле email и скрытое поле токена. Сайт задаёт уникальный nonce, связанный с сессией. Сервер должен проверить подпись и соответствие полученных данных ожидаемому сценарию. Подтверждение владения адресом и авторизация в собственном аккаунте — разные операции. Ошибка проверки токена не должна превращаться в молчаливое создание доверенной сессии. Для клиентов без поддержки сохраняется другой путь подтверждения, чтобы экспериментальная возможность не делала регистрацию недоступной. В руководстве верификатора DNS-запись домена связывает адрес почты с допустимым издателем. Далее используются опубликованные метаданные издателя и набор JWKS. Это исключает предположение, будто любой сервер, подписавший произвольный JSON, может подтвердить владение чужим адресом. Внутри пакета key binding содержит аудиторию и nonce конкретной формы. Само значение email_verified поэтому является только одним полем среди нескольких обязательных проверок. Выдача доказательства и приём доказательства разделены между двумя участниками протокола.
Обнаружение ключа не всегда начинается с kid
Email Verification Token подписан провайдером, а набор публичных ключей публикуется как JWKS. Октябрьский разбор напоминает, что идентификатор kid может отсутствовать, в том числе в токенах Gmail. Проверка должна учитывать такой допустимый вариант, а не считать отсутствие поля автоматическим свидетельством подделки. Одновременно сама подпись остаётся обязательной: перебор подходящих опубликованных ключей не означает принятие непроверенного содержимого. Документация разделяет обязанности сайта, проверяющего адрес, и провайдера, выпускающего доказательство.
Протокол уточняет данные и контекст запроса
Начиная с Chrome 156 адрес в токене должен возвращаться ровно в виде, переданном формой. Со стороны провайдера несоответствие приводит к отказу браузера. Для запросов выпуска токена с Chrome 154 изменено значение Sec-Fetch-Dest: теперь email-verification с дефисом. Google советует на переходном этапе учитывать обе формы заголовка. Эти детали важны для совместимости, но не заменяют проверку доверенного издателя и параметров токена. Стороннее испытание также ограничено отношением same-site между регистрантом и издателем.
Токен испытания и токен пользователя имеют разные сроки
Руководство сообщает о продлении origin trial до Chrome 160. Ранее выданные разрешения на участие в испытании истекают 17 ноября 2026 года. Сам пользовательский EVT имеет отдельные iat и exp, а также привязку к аудитории и nonce формы. Поэтому срок эксперимента и срок доказательства владения почтой — разные ограничения. Пустое поле токена допускает отсутствие поддержки или отказ пользователя от подтверждения; документация сохраняет в таком случае обычный маршрут с письмом. Формат включает подпись издателя и key binding, связывающий доказательство с конкретным обращением. Это предотвращает трактовку произвольного содержимого скрытого поля как уже подтверждённого адреса.
