Изменения в FedCM в Chrome 143: структурированные утверждения ID, более строгие метаданные клиента и обновления API

Chrome 143 (опубликован 12 января 2026 года) вводит несколько изменений в FedCM (Управление федеративными учетными данными), которые имеют непосредственное значение для команд полного стека, разрабатывающих потоки входа в веб. Обновление позволяет поставщикам идентификации (IdP) возвращать структурированный JSON в утверждении ID, ужесточает проверку client_metadata (браузер начнет применять обязательные поля) и вносит несколько разрушающих изменений в API/формат, которые будут применены в Chrome 145. (developer.chrome.com)

Почему это важно

• Это не необязательные изменения в UX: они изменяют формат данных, которые возвращают ваши конечные точки IdP, и то, что Chrome будет принимать при сопоставлении RP с IdP. Если вы хостите IdP или полагаетесь на интегрированный вход FedCM, это изменение может привести к молчаливому сбою входа, как только Chrome 145 будет выпущен.
• Изменения затрагивают как клиентский код (вызовы navigator.credentials.get(), обработка ошибок и место, где вы включаете nonce), так и серверные конечные точки (.well-known/web-identity и ответ на утверждение ID).
• Chrome предоставляет переходный период (Chrome 143–144), в течение которого старое и новое поведение сосуществуют, но командам необходимо обновиться до применения в Chrome 145.

Ключевые технические изменения (кратко)

• Токен утверждения ID может быть структурированным объектом JSON вместо сериализованной строки (например, { token: { access_token: "...", user_info: { email: "..."} } }). Это устраняет необходимость в ручной сериализации JSON на стороне сервера и парсинга на стороне клиента. (developer.chrome.com)
• Проверка client_metadata стала более строгой: если вы используете конечную точку client_metadata, ваш .well-known/web-identity должен включать accounts_endpoint и login_url; Chrome 145 будет применять проверку accounts_endpoint. (developer.chrome.com)
• Изменения формата API / ошибок: верхний уровень nonce перемещается в объект params, используемый с navigator.credentials.get(...), а IdentityCredentialError.code переименовывается в IdentityCredentialError.error — обрабатывайте оба во время перехода. (developer.chrome.com)

Практический контрольный список для команд полного стека (высокое влияние, низкое трение)

• Обновите ответы утверждений ID IdP
  • Возвращайте реальный объект JSON для token (не JSON-строку). Добавьте любые дополнительные утверждения под стабильной структурой (access_token, user_info и т. д.).
  • Убедитесь, что логика подписи/проверки на стороне сервера принимает структурированный формат токена, который ожидает ваш RP.
• Проверьте и опубликуйте метаданные well-known
  • Убедитесь, что ваш .well-known/web-identity включает обязательные поля: как минимум accounts_endpoint и login_url.
  • Протестируйте обнаружение конечных точек и формы ответов на этапе с использованием Chrome 143.
• Обновите интеграцию клиента
  • Переместите nonce в объект params, передаваемый в navigator.credentials.get({...}). Избегайте верхнего уровня nonce.
  • Обновите обработку ошибок, чтобы проверять как e.error, так и e.code в течение переходного периода 143–144.
  • Добавьте обнаружение функций и плавный откат для браузеров, которые не поддерживают новые форматы.
• Проверьте поведение и регрессии в разных браузерах
  • Запустите сквозные тесты с Chrome 143+ и с более старыми браузерами. Используйте демонстрацию FedCM и рекомендации по реализации в документации Chrome для проверки потоков. (developer.chrome.com)
• Развертывание с телеметрией и поэтапными флагами функций
  • Разверните изменения на сервере за переключателем, включите для небольшой доли трафика и отслеживайте уровни отказов аутентификации и оттока пользователей перед полным развертыванием.
  • Добавьте логирование для обнаружения, выборок .well-known и ошибок парсинга утверждений идентичности.
• CI / безопасность
  • Добавьте тест, который извлекает .well-known и проверяет наличие обязательных ключей client_metadata.
  • Если вы IdP, рассматривайте это изменение как изменение, нарушающее совместимость, и уведомите RP или клиентов с помощью руководств по интеграции.

Сроки и риски

• Переходный период: Chrome 143–144 поддерживает как старые, так и новые форматы. Применение начнется в Chrome 145 — обновитесь до этого выпуска, чтобы избежать сбоев в производстве. (developer.chrome.com)
• Уровень риска: высокий для IdP и RP, которые не проверили свои .well-known и парсинг утверждений; средний для потребительских сайтов, использующих сторонние IdP (подтвердите с поставщиками).

Итог Если ваш стек обрабатывает вход с помощью FedCM (либо как IdP, либо как RP), рассматривайте это как изменение API на уровне платформы: обновите выходные данные утверждений ID, опубликуйте обязательные метаданные, измените обработку nonce/ошибок клиента и протестируйте в Chrome 143 сейчас. Используйте переходный период 143–144, чтобы безопасно внести изменения перед применением в Chrome 145. (developer.chrome.com)

Источник: (Chrome для разработчиков) (developer.chrome.com)

Источник

• Источник