Actualizaciones de FedCM: Desconexión de la API y dos actualizaciones

Eiji Kitamura

A partir de Chrome 122, está disponible la API de desconexión para la API de Federated Credential Management (FedCM). La API de Desconectar permite que los usuarios de confianza desconecten a sus usuarios de la cuenta del proveedor de identidad sin depender de cookies de terceros. Además, hay un par de actualizaciones para el control del mismo sitio de FedCM.

Desconectar API

Cuando un usuario crea una cuenta en un usuario de confianza (RP, el sitio que usa el proveedor de identidad para la autenticación) a través de la federación de identidades, el proveedor de identidad (IdP, el servicio que proporciona información de la cuenta y autenticación a otras partes) suele registrar la conexión en su servidor. La conexión almacenada permite que el IdP realice un seguimiento de los RP a los que accedió el usuario y optimice su experiencia. Por ejemplo, para tener una mejor experiencia cuando el usuario más tarde vuelva al RP, la cuenta de usuario con el IdP se trata como una cuenta recurrente, lo que permite funciones como la reautenticación automática y botones personalizados que muestran la cuenta utilizada.

A veces, los IdP ofrecen una API para desconectar la cuenta de un RP. Sin embargo, un flujo de desconexión está autenticado y requiere las cookies del IdP. En un mundo sin cookies de terceros, cuando el usuario visita el RP, no hay una API del navegador para que el RP se desconecte del IdP. Debido a que puede haber varias cuentas de IdP del mismo IdP vinculadas a un RP determinado, el flujo de desconexión requiere saber qué cuenta se desconecta.

La API de Desconectar le permite al usuario desconectar la cuenta de IdP del RP en el navegador y en el servidor del IdP, ya que la indica al extremo especificado. El usuario debe haber pasado por la federación de identidades mediante la API de Federated Credential Management (FedCM). Una vez que el usuario se desconecta, se lo trata como un usuario nuevo la próxima vez que intente acceder al RP con el IdP.

Desconecta el IdP del RP

Si un usuario ya accedió al RP con el IdP a través de FedCM, el navegador memoriza la relación de forma local como la lista de cuentas conectadas. El RP puede iniciar una desconexión invocando la función IdentityCredential.disconnect(). Se puede llamar a esta función desde un fotograma de RP de nivel superior. El RP debe pasar un configURL, el clientId que usa debajo del IdP y un accountHint para que se desconecte el IdP. Una sugerencia de la cuenta puede ser una string arbitraria siempre que el extremo de desconexión pueda identificar la cuenta, por ejemplo, una dirección de correo electrónico o un ID de usuario que no coincida necesariamente con el ID de la cuenta que proporcionó el extremo de la lista de cuentas:

// 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() muestra un Promise. Esta promesa puede generar una excepción por los siguientes motivos:

  • El usuario no accedió al RP con el IdP a través de FedCM.
  • La API se invoca desde un iframe sin la política de permisos de FedCM.
  • La configURL no es válida o falta el extremo de desconexión.
  • Falla la verificación de la Política de Seguridad del Contenido (CSP).
  • Hay una solicitud de desconexión pendiente.
  • El usuario inhabilitó FedCM en la configuración del navegador.

Cuando el extremo de desconexión del IdP muestra una respuesta, el RP y el IdP se desconectan en el navegador y se resuelve la promesa. Las cuentas de usuario que se desconectan se especifican en la respuesta del extremo de desconexión.

Establece el archivo de configuración del IdP

Para admitir la API de desconexión, el IdP debe admitir un extremo de desconexión y proporcionar la propiedad disconnect_endpoint y su ruta de acceso en su archivo de configuración de IdP.

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

Desconecta la cuenta en el extremo de desconexión

Cuando se invoca IdentityCredential.disconnect(), el navegador envía una solicitud POST de origen cruzado con cookies y un tipo de contenido de application/x-www-form-urlencoded a este extremo de desconexión con la siguiente información:

Propiedad Descripción
account_hint Una sugerencia para la cuenta de IdP.
client_id Es el identificador de cliente del 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

Al recibir la solicitud, el servidor de IdP debe hacer lo siguiente:

  1. Responde a la solicitud con CORS (uso compartido de recursos entre dominios).
  2. Verifica que la solicitud contenga un encabezado HTTP Sec-Fetch-Dest: webidentity.
  3. Haz coincidir el encabezado Origin con el origen del RP determinado por client_id. Recházalas si no coinciden.
  4. Busca la cuenta que coincida con account_hint.
  5. Desconecta la cuenta de usuario de la lista de cuentas conectadas del RP.
  6. Responde al navegador con el account_id del usuario identificado en formato JSON.

Una carga útil de JSON de respuesta de ejemplo se ve de la siguiente manera:

{
  "account_id": "account456"
}

Si el IdP desea que el navegador desconecte todas las cuentas asociadas con el RP, pasa una cadena que no coincida con ningún ID de cuenta, por ejemplo, "*".

Ahora se omite la verificación de /.well-known/web-identity cuando el RP y el IdP son del mismo sitio

Cuando se desarrolla un sistema FedCM, los dominios del servidor de RP de prueba o etapa de pruebas pueden ser los subdominios del servidor del IdP de producción. Por ejemplo, el servidor de IdP de producción está en idp.example, y el servidor del RP de etapa de pruebas y el servidor del IdP de etapa de pruebas están en staging.idp.example. Sin embargo, como el archivo conocido debe colocarse en la raíz del eTLD+1 del servidor del IdP, debe estar en idp.example/.well-known/web-identity y es el servidor de producción. Dado que no es necesariamente posible que los desarrolladores coloquen archivos en el entorno de producción mientras están en desarrollo, esto evita que prueben FedCM.

A partir de Chrome 122, si el dominio de RP y el dominio de IdP son iguales, Chrome no verifica el archivo conocido. De esta manera, los desarrolladores podrán realizar pruebas en esa situación.

Ahora los subrecursos pueden establecer el estado de acceso al mismo sitio

Anteriormente, Chrome solo permitía configurar el estado de acceso (por ejemplo, mediante el encabezado Set-Login: logged-in) cuando la solicitud era del mismo origen con todos los principales. Esto evitó los accesos mediante las solicitudes del mismo sitio que fetch() configuraban el estado de acceso.

Por ejemplo, piensa en un sitio web que permite a los usuarios ingresar su nombre de usuario y contraseña en idp.example, pero las credenciales se publican en login.idp.example con fetch(). No se pudo registrar el estado de acceso en el navegador con la API de estado de acceso porque los dos dominios son de origen cruzado y del mismo sitio.

Con este cambio, flexibilizamos el requisito para que la API de estado de acceso sea del mismo sitio con todos los principales y permite que el ejemplo anterior configure el estado de acceso de login.idp.example con un encabezado HTTP (Set-Login: logged-in).

Resumen

Cuando se usa la API de Desconectar, FedCM ahora puede desconectar el RP del IdP sin depender de cookies de terceros. Para hacerlo, llama a IdentityCredential.disconnect() en el RP. Con esta función, el navegador envía una solicitud al extremo de desconexión del IdP para que este pueda finalizar la conexión en el servidor y, luego, en el navegador.

Anunciamos que se omite la verificación de /.well-known/web-identity cuando el RP y el IdP son el mismo sitio con fines de prueba. Además, ahora es posible configurar un estado de acceso a través de un encabezado de respuesta HTTP desde el subrecurso de IdP del mismo sitio.