FedCM и конфиденциальность браузера: вход через аккаунт

Federated Credential Management, или FedCM, предоставляет управляемый браузером путь, по которому поставщик идентификации помогает доверяющей стороне выполнить вход. В зависимости от аккаунта и прежнего разрешения браузер может попросить пользователя выбрать или подтвердить аккаунт; подходящий возвращающийся пользователь может пройти автоматическую повторную аутентификацию без того же окна выбора. Приложение должно различать первое одобрение и повторный вход и не считать, что каждый сценарий показывает окно выбора аккаунта. Приложению не нужно считать встроенный сервис поставщика неограниченным хранилищем сторонних cookies.

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

Свяжите каждый публичный сценарий с текущим алгоритмом входа доверяющей стороны в спецификации FedCM W3C: там описаны запрос signin и возвращаемое удостоверение; первоначальное создание аккаунта описывает раздел запрос разрешения на регистрацию; автоматическая повторная аутентификация возвращающегося аккаунта является ветвью того же алгоритма для подходящего аккаунта. Читатель может проверить границу, записав, использовал ли тест signin, появилось ли окно разрешения, было ли IdentityCredential.isAutoSelected равно true и принял ли сервер audience и срок действия. Ни одно наблюдение само по себе не разрешает аккаунт, а отсутствие окна не доказывает неизвестность человека или устройства.

Что меняет посредничество браузера

Обычный федеративный вход перенаправляет к поставщику или встраивает его содержимое. Раньше встроенный поставщик мог полагаться на стороннюю cookie для хранения сеанса. FedCM переносит выбор аккаунта и часть обмена в контролируемое браузером окно после решения пользователя.

Браузер не решает, разрешен ли аккаунт приложению. Сервер доверяющей стороны проверяет issuer, audience, срок, привязку запроса и подпись, а затем применяет собственные правила связи аккаунтов. Успешное подтверждение в диалоге не доказывает авторизацию, а отсутствие диалога не описывает человека или устройство.

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

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

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

Контракт доверяющей стороны

Начните с пользовательского пути: где запрашивается вход, какие аккаунты предлагаются, какое уведомление нужно и какое состояние переживает отмену или повтор. Утверждение должно завершать узкую видимую задачу, например создавать сеанс или связывать аккаунт.

Связь аккаунтов должна быть явной. Если пользователь уже вошел локально, сообщите, войдет ли новый аккаунт, будет связан или заменит текущий. Перед объединением требуется действие пользователя; при конфликте сохраняйте текущую работу и дайте восстановление.

Сервер проверяет каждый ответ: issuer, audience, nonce или привязку, срок и подпись. Ограничьте частоту ошибок и детерминированно обрабатывайте повтор. В журнале оставляйте обезличенную стадию ошибки, а не полный токен.

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

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

Согласие, раскрытие и контроль

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

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

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

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

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

Сторонние cookies и границы хранилища

FedCM уменьшает зависимость от сторонних cookies, но не дает общего исключения для хранилища данных. Поставщик не должен считать cookie в iframe доступной после одобрения. Доверяющая сторона хранит собственный сеанс, а поставщик описывает путь первой стороны для управления аккаунтом.

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

Не используйте результат FedCM как цифровой отпечаток. Диалог может отсутствовать из-за браузера, аккаунта, настройки, разрешения, политики или версии. Выбирайте ветку по функции, а не по свойствам и задержкам.

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

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

Надежный резервный путь

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

Путь первой стороны использует короткий переход, авторизованный сервером. Учетные данные не помещаются в URL; ссылка привязывается к доверяющей стороне, действию и сроку, затем становится недействительной. После отмены сохраните форму и верните пользователя на известный экран.

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

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

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

Матрица приемки резервного пути аккаунта

Используйте как источники протокола алгоритм входа доверяющей стороны W3C и справочник API FedCM на MDN. Выполняйте каждую строку с синтетическими аккаунтами и принимайте ее только при совпадении наблюдаемого результата с контрактом приложения.

Наблюдаемое начальное условие	Основное действие	Видимый пользователю резервный путь	Доказательство приемки
FedCM недоступен или поставщик не может предложить аккаунт	Не открывайте средство выбора	Предложите путь первой стороны поставщика или одобренное восстановление	Учетные данные не отправляются; объявляется резервная страница; сеанс доверяющей стороны отсутствует до серверной проверки
Пользователь отказывает средству выбора	Завершите попытку FedCM	Оставьте открытое содержимое и покажите локальный вход или восстановление	В событии указано declined; текущая работа сохранена; сеанс не создан
Пользователь отменяет, переход просрочен или сервер превысил время ожидания	Остановите обмен и сделайте ссылку недействительной	Верните на известный экран с ограниченной повторной попыткой	Страница сообщает о незавершенном входе, черновик сохранен, а повтор не использует просроченную ссылку
Утверждение не проходит проверку issuer, audience, nonce, подписи или срока	Отклоните ответ на сервере	Покажите одобренное восстановление	Сервер возвращает неуспешный результат, хранит только обезличенную стадию, а интерфейс не сообщает об успешном входе
Возвращенный аккаунт конфликтует с активным локальным аккаунтом	Не связывайте и не заменяйте записи автоматически	Попросите явно выбрать связывание, смену или восстановление	Работа и сеанс не меняются до подтверждения; итоговый сеанс относится к одному аккаунту

Сквозная приемка

Используйте приведенные выше алгоритм W3C и справочник API MDN как источники шагов браузера, а документированную конфигурацию поставщика как источник сведений о доступности. В обычном продуктном сценарии пользователь нажимает Войти, доверяющая сторона вызывает FedCM в чистом тестовом профиле, а настроенный поставщик предлагает синтетический аккаунт. Браузер показывает средство выбора; после одобрения доверяющая сторона отправляет утверждение на сервер. Сервер проверяет issuer, audience, nonce, подпись и срок действия, создает ровно один сеанс доверяющей стороны и возвращает пользователя к сохраненной задаче с доступным сообщением об успехе. Пакет доказательств содержит стадию, категорию поставщика, результат проверки, результат сеанса и видимое сообщение, но не само утверждение.

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

Наблюдаемый результат	Как отличить	Требуемый результат приемки
API недоступен	navigator.credentials или метод FedCM отсутствует либо заблокирован до запроса поставщику	Средство выбора и обмен учетными данными не запускаются; покажите одобренный путь первой стороны и запишите api_unavailable
Отказ пользователя	Средство выбора показано, а синтетический пользователь отменил или отказал	Запишите declined; сохраните задачу; не создавайте сеанс; предложите локальный вход или восстановление
Конфигурация поставщика	API вызывается, но поставщик не соответствует требованиям или не может предложить настроенный тестовый аккаунт	Запишите provider_not_configured или provider_account_unavailable; не отправляйте утверждение на создание сеанса; покажите путь поставщика или восстановление
Серверная проверка утверждения	Результат средства выбора достиг сервера, но не проходит issuer, audience, nonce, подпись или срок	Верните неуспешный результат, запишите только обезличенную стадию проверки, не создавайте сеанс и покажите восстановление

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

Тестирование на синтетических аккаунтах

Используйте аккаунты поставщика и доверяющей стороны в тестовой среде. Раздельно проверяйте чистый и возвращенный профиль. Не помещайте личные адреса, утверждения из рабочей среды или реальные коды восстановления доступа в тестовые наборы; назначьте владельцев удаления.

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

Добавьте два синтетических аккаунта, аккаунт, связанный с другим локальным пользователем, просроченный сеанс поставщика и аккаунт, который нельзя предложить. Не заменяйте работу и не объединяйте записи молча.

Сравнивайте браузеры при одинаковых версиях, конфигурации поставщика и данных. Записывайте доступность FedCM, отображаемый диалог, действие, серверный результат и резервный путь. Изменение версии обновляет матрицу поддержки, но не становится правилом всех платформ.

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

В автоматизации один владелец управляет профилем каждого сеанса. Руководство Selenium описывает изоляцию, версии и закрытие. Утверждения FedCM должны проверять границу приложения, а не список свойств цифрового отпечатка.

Проверка выпуска и эксплуатация

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

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

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

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

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

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

Доступность и локализация входят в контракт. Переводите имя поставщика, цель, отказ и восстановление доступа без изменения смысла. Тестируйте длинные имена, RTL при поддержке, масштаб, уменьшение движения и клавиатуру.

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

Открытые источники

Указанный здесь документ W3C о FedCM является первым публичным рабочим черновиком, а страница API на MDN отмечает ограниченную и экспериментальную совместимость. Используйте эти страницы как источники сведений о протоколе и совместимости, а затем проверьте поставщика, версию браузера и серверный контракт, которые приложение действительно поддерживает.

• MDN: Federated Credential Management API
• Спецификация W3C FedCM: вход доверяющей стороны
• Chrome for Developers: Federated Credential Management