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

Eiji Kitamura

A partir de Chrome 122, la API de Desconectar para Credencial federada La API de Management (FedCM) está disponible. El La API de Desconectar permite a los usuarios confiables desconectar a sus usuarios del del proveedor de identidad sin depender de cookies de terceros. Además, hay hay un par de actualizaciones en la administración en el mismo sitio de FedCM.

Desconectar API

Cuando un usuario crea una cuenta en un usuario de confianza (RP, el sitio que utiliza el de identidad para la autenticación) a través de la federación de identidades, de servicios (IdP, el servicio que proporciona autenticación e información de la cuenta) a otras partes) registra la conexión en su servidor. Los almacenes de datos permite que el IdP haga un seguimiento de las RP a las que el usuario accedió optimizar su experiencia. Por ejemplo, para tener una mejor experiencia cuando usuario vuelve al RP, la cuenta de usuario con el IdP se trata como un 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 el flujo de desconexión se autentica y requiere las cookies del IdP. En un mundo sin cookies de terceros, cuando el usuario visita la parte restringida, no hay navegador API para que el RP se desconecte del IdP. Porque puede haber varios IdP del mismo IdP vinculado a una RP determinada, el flujo de desconexión requiere saber qué cuenta se está desconectando.

La desconexión API Permite que el usuario también desconecte la cuenta del IdP del RP en el navegador como en el servidor de IdP cuando se lo indica al extremo especificado. El usuario necesita que haya pasado por la federación de identidades con de Google Cloud Management (FedCM). Una vez que se desconecta al usuario, se lo trata como un dispositivo nuevo. usuario la próxima vez que intente acceder al RP mediante el IdP.

Desconecta el IdP del RP

Si un usuario ya accedió al RP mediante el IdP a través de FedCM, el relación es memorizada por el navegador localmente como la lista de redes cuentas de servicio. El RP puede iniciar una desconexión invocando la función IdentityCredential.disconnect(). Se puede llamar a esta función desde un marco RP de nivel superior. El RP debe pasar un configURL, el clientId que usa en el IdP, y un accountHint para que el IdP se desconecte. Una cuenta hint puede ser una cadena arbitraria siempre que el extremo de desconexión pueda identificar la cuenta, como una dirección de correo electrónico o un ID de usuario, que no necesariamente coincida 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 arrojar una excepción por los siguientes motivos:

  • El usuario no accedió al RP mediante 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.
  • Falló 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 devuelve un respuesta, el RP y el IdP se desconectan en el navegador y se resuelve la promesa. Las cuentas de usuario que se desconectan se especificado en la respuesta a la desconexión extremo.

Configura el archivo de configuración del IdP

Para admitir la API de Disconnect, el IdP debe admitir una desconexión y proporciona la propiedad disconnect_endpoint y su ruta en su IdP de configuración.

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

Desconectar la cuenta en el extremo desconexión

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

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

Después de recibir la solicitud, el servidor de IdP debe hacer lo siguiente:

  1. Responde a la solicitud con CORS (recurso multiorigen) Uso compartido).
  2. Verifica que la solicitud contenga un encabezado HTTP Sec-Fetch-Dest: webidentity.
  3. Haz coincidir el encabezado Origin con el origen de la RP determinado por el client_id. Recházala 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 un archivo JSON de un conjunto de datos tengan un formato común.

Una carga útil de ejemplo de respuesta JSON 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 el mismo sitio

Al desarrollar un sistema FedCM, probar o almacenar en etapa intermedia los dominios del servidor RP pueden ser subdominios del servidor de IdP de producción. Por ejemplo, el servidor IdP de producción está en idp.example, y tanto en el servidor RP de etapa de pruebas como en el servidor de IdP de etapa de pruebas son en staging.idp.example. Sin embargo, dado que el archivo conocido se debe colocar en la raíz del eTLD+1 del servidor de IdP, debe estar en idp.example/.well-known/web-identity, que es el servidor de producción. Desde no es posible que los desarrolladores coloquen archivos en un entorno de desarrollo, lo que evita que prueben FedCM.

A partir de Chrome 122, si el dominio RP y el dominio de IdP son iguales, Chrome omite la comprobación del archivo conocido. De esta manera, los desarrolladores podrán probar tal situación.

Ahora los recursos secundarios pueden establecer el estado de acceso del mismo sitio

Anteriormente, Chrome solo permitía establecer la información de acceso estado (para ejemplo, con el encabezado Set-Login: logged-in) cuando la solicitud es la mismo origen con todos los principales. Esto impidió el acceso mediante mismo sitio fetch() solicita configurar 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(). Registrar el estado de acceso en el navegador con el Estado de acceso No era posible usar la API porque los dos dominios son de origen cruzado y del mismo sitio.

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

Resumen

Mediante 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 el IdP pueda finalizar el conexión en el servidor y, luego, en el navegador.

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