В Chrome 122 доступен Disconnect API для API федеративного управления учетными данными (FedCM) . API Disconnect позволяет проверяющим сторонам отключать своих пользователей от учетной записи поставщика удостоверений, не полагаясь на сторонние файлы cookie. Кроме того, есть несколько обновлений для обработки одного и того же сайта FedCM.
Отключить API
Когда пользователь создает учетную запись на проверяющей стороне (RP — сайт, использующий поставщика удостоверений для аутентификации) посредством федерации удостоверений, поставщик удостоверений (IdP — служба, которая предоставляет аутентификацию и информацию об учетной записи другим сторонам) обычно записывает соединение на своем сервер. Сохраненное соединение позволяет IdP отслеживать RP, в которые вошел пользователь, и оптимизировать его работу. Например, чтобы пользователю было удобнее возвращаться к RP позже, учетная запись пользователя с IdP рассматривается как возвращающаяся учетная запись, что позволяет использовать такие функции, как автоматическая повторная аутентификация и персонализированные кнопки, показывающие использованную учетную запись.
Иногда поставщики удостоверений предлагают API для отключения учетной записи от RP. Однако поток отключения проходит проверку подлинности и требует файлов cookie IdP. В мире, где нет сторонних файлов cookie, когда пользователь посещает RP, не существует API браузера, позволяющего RP отключиться от IdP. Поскольку с одним и тем же RP может быть связано несколько учетных записей IdP от одного и того же IdP, для процесса отключения необходимо знать, какая учетная запись отключается.
API Disconnect позволяет пользователю отключить учетную запись IdP от RP в браузере, а также на сервере IdP, отправив сигнал об этом указанной конечной точке. Пользователь должен пройти федерацию удостоверений с помощью API федеративного управления учетными данными (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
Чтобы поддерживать Disconnect API, поставщик удостоверений должен поддерживать конечную точку отключения и предоставить свойство disconnect_endpoint и путь к нему в своем файле конфигурации IdP .
{
"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 должен:
- Ответьте на запрос с помощью CORS (совместное использование ресурсов между источниками) .
- Убедитесь, что запрос содержит HTTP-заголовок
Sec-Fetch-Dest: webidentity. - Сопоставьте заголовок
Originс источником RP, определеннымclient_id. Отклонить, если они не совпадают. - Найдите учетную запись, соответствующую
account_hint. - Отключите учетную запись пользователя из списка подключенных учетных записей RP.
- Ответьте браузеру, указав
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 . Однако, поскольку общеизвестный файл должен располагаться в корне 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 ).
Краткое содержание
Используя Disconnect API, FedCM теперь может отключить RP от IdP, не полагаясь на сторонние файлы cookie. Для этого вызовите IdentityCredential.disconnect() на RP. С помощью этой функции браузер отправляет запрос на конечную точку отключения IdP, чтобы IdP мог разорвать соединение на сервере, а затем в браузере.
Мы объявили, что проверка /.well-known/web-identity пропускается, если RP и IdP находятся на одном сайте, в целях тестирования. Кроме того, теперь можно установить статус входа через заголовок ответа HTTP из подресурса IdP того же сайта.