Chrome 120 поставляется с API статуса входа для FedCM. API статуса входа (ранее известный как API статуса входа в систему IdP) позволяет веб-сайтам, особенно поставщикам удостоверений, сигнализировать браузеру, когда их пользователи входят в систему и выходят из нее. Этот сигнал используется FedCM для решения проблемы скрытой временной атаки и при этом позволяет FedCM работать вообще без сторонних файлов cookie . Это обновление устраняет последние оставшиеся обратно несовместимые изменения, которые мы ранее определили в исходном намерении выпустить FedCM , как часть нашего объема работ .
Хотя API статуса входа улучшает конфиденциальность и удобство использования, после поставки это изменение несовместимо с предыдущими версиями. Если у вас есть существующая реализация FedCM, обязательно обновите ее, используя следующие инструкции.
Кроме того, Chrome предлагает две новые функции Federated Credential Management (FedCM) :
- API ошибок : уведомляйте пользователей, когда их попытка входа не удалась, с помощью собственного пользовательского интерфейса на основе ответа сервера от конечной точки утверждения идентификатора, если таковая имеется.
- API флага автоматического выбора : уведомите поставщика удостоверений (IdP) и проверяющую сторону (RP), если учетные данные были автоматически выбраны в потоке.
API статуса входа
API статуса входа — это механизм, с помощью которого веб-сайт, особенно поставщик удостоверений личности, сообщает браузеру статус входа пользователя в поставщика удостоверений. С помощью этого API браузер может сократить количество ненужных запросов к IdP и снизить потенциальные атаки по времени.
Информировать браузер о статусе входа пользователя
IdP могут сообщать браузеру о статусе входа пользователя, отправляя HTTP-заголовок или вызывая API JavaScript, когда пользователь входит в систему IdP или когда пользователь выходит из всех своих учетных записей IdP. Для каждого IdP (идентифицированного по URL-адресу конфигурации) браузер сохраняет переменную с тремя состояниями, представляющую состояние входа в систему с возможными значениями: logged-in , logged-out » и unknown . Состояние по умолчанию unknown .
Чтобы сигнализировать о том, что пользователь вошел в систему, отправьте HTTP-заголовок Set-Login: logged-in в навигации верхнего уровня или запрос подресурса того же происхождения:
Set-Login: logged-in
Альтернативно вызовите API JavaScript navigator.login.setStatus('logged-in') из источника IdP:
navigator.login.setStatus('logged-in');
Эти вызовы записывают статус входа пользователя как logged-in . Когда для статуса входа пользователя установлено logged-in , RP, вызывающая FedCM, отправляет запросы к конечной точке списка учетных записей IdP и отображает доступные учетные записи пользователю в диалоговом окне FedCM.
Чтобы сигнализировать о том, что пользователь вышел из всех своих учетных записей, отправьте HTTP-заголовок Set-Login: logged-out в навигации верхнего уровня или запрос подресурса того же происхождения:
Set-Login: logged-out
Альтернативно вызовите API JavaScript navigator.login.setStatus('logged-out') из источника IdP:
navigator.login.setStatus('logged-out');
Эти вызовы записывают статус входа пользователя в систему как logged-out . Когда статус входа пользователя logged-out , вызов FedCM автоматически завершается неудачей без выполнения запроса к конечной точке списка учетных записей IdP.
unknown статус устанавливается до того, как поставщик удостоверений отправит сигнал с помощью API статуса входа. Мы ввели этот статус для более удобного перехода, поскольку пользователь, возможно, уже вошел в IdP, когда мы выпускаем этот API. У IdP может не быть возможности сообщить об этом браузеру к моменту первого вызова FedCM. В этом случае мы делаем запрос к конечной точке списка учетных записей IdP и обновляем статус на основе ответа от конечной точки списка учетных записей:
- Если конечная точка возвращает список активных учетных записей, обновите статус до
logged-inи откройте диалоговое окно FedCM, чтобы отобразить эти учетные записи. - Если конечная точка не возвращает учетных записей, обновите статус до
logged-outи откажитесь от вызова FedCM.
Что делать, если срок действия сеанса пользователя истекает? Позвольте пользователю войти в систему с помощью динамического процесса входа!
Несмотря на то, что IdP продолжает сообщать браузеру статус входа пользователя, статус может быть не синхронизирован, например, по истечении срока действия сеанса. Браузер пытается отправить запрос с учетными данными в конечную точку списка учетных записей, когда статус входа — logged-in , но сервер не возвращает учетные записи, поскольку сеанс больше не доступен. В таком сценарии браузер может динамически разрешить пользователю войти в IdP через диалоговое окно.
В диалоговом окне FedCM отображается сообщение с предложением войти в систему, как показано на следующем рисунке.
Когда пользователь нажимает кнопку «Продолжить» , браузер открывает диалоговое окно для страницы входа в систему IdP.
URL-адрес страницы входа указывается в параметре login_url как часть файла конфигурации IdP .
{
"accounts_endpoint": "/auth/accounts",
"client_metadata_endpoint": "/auth/metadata",
"id_assertion_endpoint": "/auth/idtokens",
"login_url": "/login"
}
}
Диалог представляет собой обычное окно браузера, в котором установлены основные файлы cookie. Что бы ни происходило в диалоговом окне, зависит от IdP, и нет доступных дескрипторов окон для отправки запроса на связь между источниками на странице RP. После того как пользователь вошел в систему, IdP должен:
- Отправьте заголовок
Set-Login: logged-inили вызовите APInavigator.login.setStatus("logged-in")чтобы сообщить браузеру, что пользователь выполнил вход. - Вызовите
IdentityProvider.close(), чтобы закрыть диалоговое окно.
Вы можете попробовать поведение API статуса входа в нашей демонстрации .
- Нажмите кнопку «Перейти к IdP и войти» .
- Войдите под произвольной учетной записью.
- Выберите «Сессия истекла» в раскрывающемся списке «Состояние учетной записи» .
- Нажмите кнопку «Обновить личную информацию» .
- Нажмите кнопку «Посетить RP, чтобы попробовать FedCM» .
Вы должны иметь возможность наблюдать за входом в IdP через поведение модуля.
Ошибка API
Когда Chrome отправляет запрос на конечную точку утверждения идентификатора (например, когда пользователь нажимает кнопку «Продолжить как» в пользовательском интерфейсе FedCM или запускается автоматическая повторная аутентификация), IdP может не иметь возможности выдать токен по законным причинам. Например, если клиент неавторизован, сервер временно недоступен и так далее. В настоящее время Chrome молча отклоняет запрос в случае таких ошибок и уведомляет RP только путем отклонения обещания.
С помощью Error API Chrome уведомляет пользователя, показывая собственный пользовательский интерфейс с информацией об ошибке, предоставленной поставщиком удостоверений.
HTTP API поставщика идентификационной информации
В ответе id_assertion_endpoint поставщик удостоверений может вернуть токен браузеру, если он может быть выдан по запросу. В этом предложении, если токен не может быть выдан, IdP может вернуть ответ «ошибка», который имеет два новых необязательных поля:
-
code -
url
// id_assertion_endpoint response
{
"error": {
"code": "access_denied",
"url": "https://idp.example/error?type=access_denied"
}
}
Для кода поставщик удостоверений может выбрать одну из известных ошибок из списка ошибок OAuth 2.0 [ invalid_request , unauthorized_client , access_denied , server_error и temporarily_unavailable ] или использовать любую произвольную строку. В последнем случае Chrome отображает пользовательский интерфейс ошибки с общим сообщением об ошибке и передает код RP.
Для url он идентифицирует удобочитаемую веб-страницу с информацией об ошибке, чтобы предоставить пользователям дополнительную информацию об ошибке. Это поле полезно для пользователей, поскольку браузеры не могут отображать подробные сообщения об ошибках в собственном пользовательском интерфейсе. Например, ссылки для следующих шагов, контактная информация службы поддержки клиентов и т. д. Если пользователь хочет узнать больше о деталях ошибки и способах ее устранения, он может посетить предоставленную страницу из пользовательского интерфейса браузера для получения более подробной информации. URL-адрес должен относиться к тому же сайту, что и configURL IdP.
try {
const cred = await navigator.credentials.get({
identity: {
providers: [
{
configURL: 'https://idp.example/manifest.json',
clientId: '1234',
},
],
}
});
} catch (e) {
const code = e.code;
const url = e.url;
}
API автоматически выбранного флага
mediation: optional — это поведение посредничества пользователя по умолчанию в API управления учетными данными, которое запускает автоматическую повторную аутентификацию, когда это возможно. Однако автоматическая повторная аутентификация может быть недоступна по причинам, известным только браузеру; когда он недоступен, пользователю может быть предложено войти в систему с явным посредничеством пользователя, которое представляет собой поток с различными свойствами.
- С точки зрения вызывающей стороны API, когда они получают идентификационный токен, они не могут понять, является ли это результатом потока автоматической повторной аутентификации. Из-за этого им сложно оценить производительность API и соответственно улучшить UX.
- С точки зрения IdP, они также не могут определить, произошла ли автоматическая повторная аутентификация или нет для оценки производительности. Кроме того, если бы использовалось явное посредничество пользователей, это могло бы помочь им поддерживать больше функций, связанных с безопасностью. Например, некоторые пользователи могут предпочесть более высокий уровень безопасности, который требует явного участия пользователя в аутентификации. Если IdP получает запрос токена без такого посредничества, он может обработать запрос по-другому. Например, верните код ошибки, чтобы RP мог снова вызвать API FedCM с помощью
mediation: required.
Таким образом, обеспечение видимости потока автоматической повторной аутентификации было бы полезно для разработчиков.
С помощью API-интерфейса автоматического выбора флага Chrome сообщает, было ли получено явное разрешение пользователя, путем нажатия кнопки «Продолжить как» как для IdP, так и для RP, всякий раз, когда происходит автоматическая повторная аутентификация или происходит явное посредничество. Совместное использование происходит только после того, как пользователю предоставлено разрешение на связь IdP/RP.
Совместное использование поставщика идентификационной информации
Чтобы передать информацию разрешению пользователя IdP на публикацию, Chrome включает is_auto_selected=true в запрос POST , отправленный на id_assertion_endpoint :
POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=Ct0D&disclosure_text_shown=true&is_auto_selected=true
обмен RP
Браузер может передать информацию RP в isAutoSelected через IdentityCredential :
const cred = await navigator.credentials.get({
identity: {
providers: [{
configURL: 'https://idp.example/manifest.json',
clientId: '1234'
}]
}
});
if (cred.isAutoSelected !== undefined) {
const isAutoSelected = cred.isAutoSelected;
}
Привлекайте и делитесь отзывами
Если у вас есть отзывы или вы столкнулись с какими-либо проблемами во время тестирования, вы можете поделиться ими на crbug.com .
Фото Девушка в красной шляпе на Unsplash