Обновления FedCM: Disconnect API и два обновления

Эйдзи Китамура

Начиная с Chrome 122, доступен API Disconnect для API Federated Credential Management (FedCM) . API Disconnect позволяет проверяющим сторонам отключать своих пользователей от учетной записи поставщика удостоверений, не полагаясь на сторонние файлы cookie. Кроме того, есть несколько обновлений для обработки на том же сайте FedCM.

API отключения

Когда пользователь создает учетную запись на проверяющей стороне (RP — сайт, использующий поставщика удостоверений для аутентификации) через федерацию удостоверений, поставщик удостоверений (IdP — служба, которая предоставляет аутентификацию и учетную информацию другим сторонам) обычно записывает соединение на своем сервере. Сохраненное соединение позволяет IdP отслеживать RP, в которые вошел пользователь, и оптимизировать их взаимодействие. Например, чтобы обеспечить лучший опыт, когда пользователь позже вернется в RP, учетная запись пользователя с IdP рассматривается как возвращающаяся учетная запись, что позволяет использовать такие функции, как автоматическая повторная аутентификация и персонализированные кнопки, показывающие используемую учетную запись.

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

API Disconnect позволяет пользователю отключать учетную запись IdP от RP в браузере, а также на сервере IdP, отправляя сигнал указанной конечной точке. Пользователь должен пройти федерацию удостоверений с использованием API Federated Credential Management (FedCM). После отключения пользователя он рассматривается как новый пользователь при следующей попытке входа в RP с использованием IdP.

Отключите IdP от RP

Если пользователь ранее входил в RP с помощью IdP через FedCM, связь запоминается браузером локально как список подключенных учетных записей. RP может инициировать отключение, вызвав функцию IdentityCredential.disconnect() . Эту функцию можно вызвать из фрейма RP верхнего уровня. RP необходимо передать configURL , clientId , который он использует в IdP, и accountHint для отключения IdP. Подсказка учетной записи может быть произвольной строкой, если конечная точка отключения может идентифицировать учетную запись, например, адрес электронной почты или идентификатор пользователя, который не обязательно совпадает с идентификатором учетной записи, предоставленным конечной точкой списка учетных записей:

// Disconnect an IdP account "account456" from the RP "https://idp.com/". This is invoked on the RP domain.
IdentityCredential.disconnect({
  configURL: "https://idp.com/config.json",
  clientId: "rp123",
  accountHint: "account456"
});

IdentityCredential.disconnect() возвращает Promise . Это обещание может выдать исключение по следующим причинам:

  • Пользователь не вошел в RP, используя IdP через FedCM.
  • API вызывается из iframe без политики разрешений FedCM.
  • Недопустимый configURL или отсутствует конечная точка отключения.
  • Проверка политики безопасности контента (CSP) не пройдена.
  • Ожидается запрос на отключение.
  • Пользователь отключил FedCM в настройках браузера.

Когда конечная точка отключения IdP возвращает ответ , RP и IdP отключаются в браузере, и обещание разрешается. Отключающиеся учетные записи пользователей указываются в ответе от конечной точки отключения .

Настройте файл конфигурации IdP

Для поддержки API Disconnect поставщик удостоверений должен поддерживать конечную точку отключения и предоставлять свойство disconnect_endpoint и его путь в своем файле конфигурации поставщика удостоверений .

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

Отключение учетной записи на конечной точке отключения

Вызывая IdentityCredential.disconnect() , браузер отправляет кросс-доменный POST запрос с файлами cookie и типом содержимого application/x-www-form-urlencoded на эту конечную точку отключения со следующей информацией:

Свойство Описание
account_hint Подсказка для учетной записи IdP.
client_id Идентификатор клиента RP. 
POST /disconnect HTTP/1.1
Host: idp.example
Origin: rp.example
Content-Type: application/x-www-form-urlencoded
Cookie: 0x123
Sec-Fetch-Dest: webidentity

account_hint=account456&client_id=rp123

Получив запрос, сервер IdP должен:

  1. Ответьте на запрос с помощью CORS (Cross-Origin Resource Sharing) .
  2. Убедитесь, что запрос содержит HTTP-заголовок Sec-Fetch-Dest: webidentity .
  3. Сопоставьте заголовок Origin с источником RP, определенным по client_id . Отклоните, если они не совпадают.
  4. Найдите учетную запись, соответствующую account_hint .
  5. Отключите учетную запись пользователя из списка подключенных учетных записей RP.
  6. Отправьте браузеру ответ с указанием account_id идентифицированного пользователя в формате JSON.

Пример полезной нагрузки JSON ответа выглядит следующим образом:

{
  "account_id": "account456"
}

Если IdP хочет, чтобы браузер вместо этого отключил все учетные записи, связанные с RP, передайте строку, которая не соответствует ни одному идентификатору учетной записи, например "*" .

Проверка /.well-known/web-identity теперь пропускается, если RP и IdP находятся на одном сайте

При разработке системы FedCM домены тестового или промежуточного сервера RP могут быть поддоменами производственного сервера IdP. Например, производственный сервер IdP находится по адресу idp.example , а промежуточный сервер RP и промежуточный сервер IdP находятся по адресу staging.idp.example . Однако, поскольку файл well-known должен быть помещен в корень eTLD+1 сервера IdP, он должен находиться по адресу idp.example/.well-known/web-identity , и это производственный сервер. Поскольку разработчики не всегда могут размещать файлы в производственной среде во время разработки, это не позволяет им тестировать FedCM.

Начиная с Chrome 122, если домен RP и домен IdP совпадают, Chrome пропускает проверку известного файла. Таким образом, разработчики смогут проводить тестирование в таком сценарии.

Подресурсы теперь могут устанавливать статус входа на том же сайте

Ранее Chrome позволял устанавливать статус входа (например, с помощью заголовка Set-Login: logged-in ) только в том случае, если запрос был одного происхождения со всеми предками. Это предотвращало входы через запросы fetch() одного сайта, устанавливающие статус входа.

Например, представьте себе веб-сайт, который позволяет пользователям вводить свое имя пользователя и пароль на idp.example , но учетные данные публикуются на login.idp.example с помощью fetch() . Запись статуса входа в браузер с помощью API статуса входа невозможна, поскольку два домена являются кросс-доменными и находятся на одном сайте.

Благодаря этому изменению мы смягчили требование к API статуса входа, чтобы он был на одном сайте со всеми предками, и сделали возможным в приведенном выше примере установку статуса входа login.idp.example с помощью заголовка HTTP ( Set-Login: logged-in ).

Краткое содержание

Используя API Disconnect, FedCM теперь может отключать RP от IdP, не полагаясь на сторонние файлы cookie. Для этого вызовите IdentityCredential.disconnect() на RP. С помощью этой функции браузер отправляет запрос на конечную точку отключения IdP, чтобы IdP мог завершить соединение на сервере, а затем в браузере.

Мы объявили, что проверка /.well-known/web-identity пропускается, когда RP и IdP находятся на одном сайте, в целях тестирования. Также теперь возможна установка статуса входа через заголовок ответа HTTP из подресурса IdP того же сайта.