Credential Management API: надёжный вход через браузер
Разберите посредничество браузера, выбор пользователя, запасной путь и обязательную проверку на сервере.
Нужна структурированная документация по теме Идентичность?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Credential Management API даёт сайту посредствуемый браузером способ запрашивать, сохранять и получать объекты учётных данных. Браузер при этом не становится поставщиком идентичности и сам не создаёт сессию. Надёжный вход связывает намерение пользователя, посредничество, проверку сервера и понятный запасной путь.
Документ W3C Credential Management Level 1 находится на этапе разработки и не является утверждённой рекомендацией W3C. Он описывает контейнер и посредничество, но его зрелость не следует считать гарантией окончательной совместимости браузеров. Справочник Credential Management API на MDN описывает интерфейсы и совместимость. Эти источники разделяют возможность API, действие пользователя и подтверждённую сессию.
Сначала Определите Контракт Входа
До вызова navigator.credentials опишите видимую задачу: продолжить работу, создать аккаунт или подтвердить чувствительное действие. Это определяет предлагаемый тип данных, текст согласия и сохранение состояния при отмене.
Считайте контейнер учётных данных границей браузера, а не базой аккаунтов. Объект выдаётся только при разрешении браузера и пользователя; политика аккаунта, сессия, права и восстановление остаются ответственностью приложения.
Назовите состояния отдельно: ожидание, намерение записано, запрос посредничества, отмена, данные получены, проверка ожидается, сессия создана и доступно восстановление. Интерфейс не объявляет успех до ответа сервера.
Явный выбор поддерживает конфиденциальность и доступность. Дайте подписанную кнопку, объясните устанавливаемую связь аккаунта и предупредите о возможном окне браузера. Не запускайте операцию при одной загрузке страницы.
Связывание аккаунтов требует отдельного согласия. Результат не должен молча менять или объединять текущую сессию. Спросите о входе, связывании или смене аккаунта и сохраните незаписанную работу.
Поймите Посредничество Браузера
API разделяет тип учётных данных и режим посредничества. Доступность зависит от браузера, поставщика, политики и текущего контекста.
Посредничество показывает требуемое участие. Тихий или условный путь может подойти вернувшемуся пользователю, обязательный путь делает действие явным. Отсутствие результата не доказывает отсутствие аккаунта или данных.
Вызов может завершиться до обращения к поставщику: контекст небезопасен, интерфейс отсутствует или политика блокирует операцию. Ветка совместимости может показать другой метод, но не создаёт данные.
Окно браузера является частью пути пользователя. Сначала объясните действие, сохраните фокус и дайте отмену. Отказ нормален; верните человека к вариантам без повторного открытия окна.
Объект может содержать чувствительные сведения. Не помещайте его в URL, аналитические метки, снимки, ошибки или заявки. Передавайте только нужные поля и записывайте обезличенный этап.
Руководство по приватности WebAuthn напоминает: возможность браузера не доказывает наличие данных или личность. То же ограничение действует здесь.
Оставьте Проверку Серверу
Сервер отвечает за аккаунт и сессию. Он проверяет обмен по типу данных и договору поставщика, связывает его с действием и доверяющей стороной, отвергает просроченные и повторные значения. Колбэк JavaScript этого не заменяет.
Связывайте запрос с короткоживущим состоянием приложения. При возврате проверяйте тип, audience при необходимости и ожидаемое действие. Проверяйте nonce или подпись только тогда, когда этого требует протокол интеграции. Для пароля и браузерных данных нужна единая политика сессии.
Создание сессии и сохранение данных различны. Результат может выполнить вход, зарегистрировать, связать или вернуть только проверенный профиль. Объясните результат и дайте выход, завершающий сессию доверяющей стороны. Этот выход сам по себе не завершает сессию поставщика и не удаляет данные, сохранённые браузером.
Ошибки должны помогать, не раскрывая существование аккаунта. Для неверных, просроченных и неизвестных данных используйте единый текст и храните только обезличенный этап, нужный для различения причин.
Восстановление принадлежит приложению. Предлагайте сброс, проверку поддержки или первый сторонний путь только при наличии такой политики. Не просите историю браузера или полный профиль; ссылка восстановления должна истекать и становиться недействительной.
Руководство по разделению хранилища объясняет различия во встроенном контексте. Считайте их результатом контекста и предложите ясную передачу на первую сторону.
Спроектируйте Запасной Путь И Доступную Обратную Связь
У устойчивого потока есть посредствуемый вариант и понятная альтернатива: пароль, страница поставщика, ссылка почты или утверждённое восстановление. Это не обход политики, а обычный путь при недоступности, отказе или истечении.
Сохраняйте работу между ветками. После закрытия окна верните известный экран с нечувствительными полями. При тайм-ауте сообщите о неизвестном результате и создайте новое состояние. До проверки нельзя показывать успех.
Доступный статус является частью корректности. Сообщайте об открытии окна, отмене и следующем действии, переносите фокус к сообщению и объясняйте отключённые элементы. Проверяйте масштаб, контраст, чтение с экрана и длинные имена.
Локализация должна сохранять смысл безопасности. Переводите поставщика, цель, отмену, истечение и восстановление, не меняя факт создания сессии. Официальные имена API оставляйте без изменений, окружающий текст переводите.
Используйте небольшую таблицу приёмки. На синтетических аккаунтах проверьте одобрение, отказ, отмену, отсутствие API, недоступность поставщика, истечение, неверный ответ, конфликт, выход и восстановление. Запишите сообщение, сессию, сохранённую работу и этап.
Не стройте поиск аккаунта на API. Отсутствие данных, блокировка метода и отказ могут дать одинаковый результат, но имеют разный смысл. Сохраняйте открытое содержимое, когда вход необязателен, и объясняйте восстановление, когда обязателен.
Проверьте Приватность И Границы Продукта
Минимизируйте данные. Собирайте только нужные поля, ограничьте хранение и доступ поддержки. Событие может содержать этап, версию, семейство браузера, категорию поставщика и видимый результат без самого объекта.
Не превращайте доступность в отпечаток. Политика, профиль, поставщик и обновления меняют результат. Он не доказывает личность, устройство, местоположение или аккаунт и не должен становиться постоянной меткой.
Проверьте границы origin и контекста. Вызывайте API из предусмотренного origin, для передачи используйте разрешённую сервером ссылку и не раскрывайте данные в строке запроса. Объясните связь компонента, первой стороны и поставщика.
Изменения проверяйте как видимые пользователю контракты. После обновления браузера, поставщика, кода аккаунтов, согласия или хранилища повторите синтетический путь и сравните окно, выбор, проверку, сессию, запасной путь и удаление.
В тестовых наборах разделяйте состояние браузера и аккаунта. Чистый профиль показывает первый вход, возвращённый профиль показывает сохранённый выбор. Помечайте наборы по цели и удаляйте после теста.
Назначьте владельца каждому переходу. Интерфейс отвечает за фокус и текст, браузер отвечает за посредничество, поставщик отвечает за аккаунт, сервер отвечает за проверку, сессию и отзыв. При сомнении сообщайте этап и владельца, а не повторяйте бесконечно.
Считайте прерывание обычным. Пользователь может закрыть окно, потерять сеть, обновить страницу или вернуться после истечения состояния. Каждая ветка должна дать сообщение и ограниченное действие; повтор создаёт новое состояние и не воспроизводит объект.
Опишите договор языком поддержки. Разделяйте браузерные данные, аккаунт поставщика, сессию доверяющей стороны и ссылку восстановления. Просите минимальный обезличенный идентификатор, никогда не пароль, полный объект или профиль.
Эти границы помогают сравнивать браузеры. Сохраняйте версию, поставщика, синтетический аккаунт и действие, записывая только видимую ветку и ответ сервера. Разница является наблюдением совместимости, а не выводом о человеке.
Записи о выпуске должны быть точными. Назовите ветку входа, поддерживаемый диапазон браузеров, запасной путь и действительность существующих сессий. Не обещайте обязательное окно или обязательную выдачу сохранённых данных: это зависит от поставщика, политики, профиля и выбора.
Ответственность за жизненный цикл должна быть видимой. Интерфейс записывает намерение и сохраняет задачу, браузер посредничает в окне, поставщик обслуживает свой аккаунт, сервер проверяет и отзывает сессию. Передача содержит короткий этап и срок, но не полный объект.
Проверка приватности включает ошибки. Отменённое окно, отсутствующий API и неверный ответ могут привести к одному экрану, но требуют разных действий. Сообщение должно подсказывать путь, телеметрия должна оставаться минимальной, а временное состояние нужно удалять после каждого отрицательного случая.
BotBrowser позволяет переносить повторяемый профиль браузера между поддерживаемыми системами для проверки собственного пути входа. Он не управляет посредничеством Credential Management API, не одобряет данные поставщика и не заменяет серверную проверку или политику сессии доверяющей стороны.
Открытые Источники
Документ W3C Credential Management Level 1 находится на этапе разработки и не является утверждённой рекомендацией W3C. Он описывает контейнер и посредничество, но не гарантирует окончательную совместимость браузеров. Справочник MDN описывает API и совместимость. Документация BotBrowser о кросс-платформенных профилях подтверждает только повторяемую проверку; реальную доступность нужно проверять по договору браузера, поставщика и сервера.
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.