A partir de Chrome 122, está disponible la API de Disconnect para la API de Federated Credential Management (FedCM). La API de Disconnect permite que las partes de confianza desconecten a sus usuarios de la cuenta del proveedor de identidad sin depender de cookies de terceros. Además, hay algunas actualizaciones en el manejo del mismo sitio de FedCM.
API de Disconnect
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 integración de identidades, el proveedor de identidad (IdP, el servicio que proporciona información de autenticación y de la cuenta 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 en los que el usuario accedió y optimice su experiencia. Por ejemplo, para tener una mejor experiencia cuando el usuario regrese a la RP más adelante, la cuenta de usuario con la AC se considera una cuenta recurrente, lo que permite funciones como la reautorización automática y los botones personalizados que muestran la cuenta que se usó.
A veces, las IdP ofrecen una API para desconectar la cuenta de un RP. Sin embargo, se autentica un flujo de desconexión y se requieren las cookies del IdP. En un mundo sin cookies de terceros, cuando el usuario visita la RP, no hay una API del navegador para que la RP se desconecte de la 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 Disconnect le permite al usuario desconectar la cuenta del IdP del RP en el navegador y en el servidor del IdP, ya que lo indica al extremo especificado. El usuario debe haber realizado la federación de identidades con la API de Federated Credential Management (FedCM). Una vez que se desconecta el usuario, se lo considera un usuario nuevo la próxima vez que intente acceder a la RP con el IdP.
Desconecta el IdP de la RP
Si un usuario accedió anteriormente a la 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 marco de RP de nivel superior. El RP debe pasar un configURL, el clientId que usa en el IdP y un accountHint para que se desconecte el IdP. Una sugerencia de cuenta puede ser una cadena 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 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ó a la RP con el IdP a través de FedCM.
- La API se invoca desde un iframe sin la política de permisos de FedCM.
- El configURL no es válido o le falta el extremo de desconexión.
- La verificación de la Política de Seguridad del Contenido (CSP) falla.
- 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.
Configura el archivo de configuración del IdP
Para admitir la API de Disconnect, la AC 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 la AC.
{
"accounts_endpoint": "/accounts",
"id_assertion_endpoint": "/assertion",
...
"disconnect_endpoint: "/disconnect"
}
Cómo desconectar 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
Cuando recibe la solicitud, el servidor de la IdP debe hacer lo siguiente:
- Responde la solicitud con CORS (uso compartido de recursos entre dominios).
- Verifica que la solicitud contenga un encabezado HTTP
Sec-Fetch-Dest: webidentity. - Haz coincidir el encabezado
Origincon el origen de RP que determinaclient_id. Rechaza la solicitud si no coincide. - Busca la cuenta que coincida con el
account_hint. - Desconecta la cuenta de usuario de la lista de cuentas conectadas del RP.
- Responde al navegador con el
account_iddel 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 la RP y la AC están en el mismo sitio.
Cuando se desarrolla un sistema de FedCM, los dominios de los servidores de RP de prueba o de preparación pueden ser los subdominios del servidor de la IdP de producción. Por ejemplo, el servidor de IdP de producción se encuentra en idp.example, y el servidor de RP y el servidor de IdP de la etapa de pruebas se encuentran en staging.idp.example. Sin embargo, como el archivo conocido debe colocarse en la raíz del eTLD+1 del servidor de la IdP, debe estar en idp.example/.well-known/web-identity y es el servidor de producción. Dado que no es posible que los desarrolladores coloquen archivos en el entorno de producción mientras están en desarrollo, esto les impide probar FedCM.
A partir de Chrome 122, si el dominio del RP y el del IdP son iguales, Chromeomite la verificación del archivo conocido. De esta manera, los desarrolladores podrán realizar pruebas en una situación de este tipo.
Las subrecursos ahora pueden establecer el estado de acceso en el mismo sitio
Anteriormente, Chrome solo permitía configurar el estado de acceso (por ejemplo, con el encabezado Set-Login: logged-in) cuando la solicitud era del mismo origen con todos los ancestros. Esto impidió los accesos a través de las solicitudes fetch() del mismo sitio que 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 fue posible registrar el estado de acceso en el navegador con la API de Login Status porque los dos dominios son de origen cruzado y del mismo sitio.
Con este cambio, flexibilizamos el requisito de que la API de Login Status sea del mismo sitio con todos los ancestros y permite que el ejemplo anterior establezca el estado de acceso de login.idp.example con un encabezado HTTP (Set-Login:
logged-in).
Resumen
Con la API de Disconnect, FedCM ahora puede desconectar el RP del IdP sin depender de cookies de terceros. Para ello, llama a IdentityCredential.disconnect() en la 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 la RP y la IdP están en el mismo sitio para realizar pruebas. Además, ahora es posible establecer un estado de acceso a través de un encabezado de respuesta HTTP desde el subrecurso de la IdP del mismo sitio.