Actualizaciones de FedCM: API de estado de acceso, API de Error y API de marcas seleccionadas automáticamente

Chrome 120 envía la API de Login Status para FedCM. La API de Login Status (antes conocida como API de IdP Sign-in Status) permite que los sitios web, en particular los proveedores de identidad, indiquen al navegador cuándo sus usuarios acceden y salen. FedCM usa este indicador para abordar un problema de ataque de sincronización silencioso y, de esta manera, permite que FedCM opere sin cookies de terceros por completo. Esta actualización aborda los últimos cambios incompatibles con versiones anteriores que identificamos anteriormente en el Intent to Ship original de FedCM, como parte de nuestro alcance del trabajo.

Si bien la API de Login Status mejora la propiedad de privacidad y la usabilidad, es un cambio que no es retrocompatible una vez que se envía. Si tienes una implementación existente de FedCM, asegúrate de actualizarla con las siguientes instrucciones.

Además, Chrome lanzará dos nuevas funciones de Administración federada de credenciales (FedCM):

  • API de Error: Notifica a los usuarios cuando su intento de acceso falle con una IU nativa según la respuesta del servidor del extremo de la aserción de ID, si corresponde.
  • API de la marca seleccionada automáticamente: Notifica al proveedor de identidad (IdP) y al usuario de confianza (RP) si se seleccionó automáticamente una credencial en el flujo.

API de Login Status

La API de Login Status es un mecanismo en el que un sitio web, en especial un IdP, informa al navegador el estado de acceso del usuario en el IdP. Con esta API, el navegador puede reducir las solicitudes innecesarias al IdP y mitigar los posibles ataques de sincronización.

Informa al navegador sobre el estado de acceso del usuario

Los IdPs pueden indicar el estado de acceso del usuario al navegador enviando un encabezado HTTP o llamando a una API de JavaScript cuando el usuario accede al IdP o cuando sale de todas sus cuentas de IdP. Para cada IdP (identificado por su URL de configuración), el navegador mantiene una variable de tres estados que representa el estado de acceso con los valores posibles logged-in, logged-out y unknown. El estado predeterminado es unknown.

Para indicar que el usuario accedió, envía un encabezado HTTP Set-Login: logged-in en una navegación de nivel superior o una solicitud de subrecurso del mismo origen:

Set-Login: logged-in

Como alternativa, llama a la API de JavaScript navigator.login.setStatus('logged-in') desde el origen de la IdP:

navigator.login.setStatus('logged-in');

Estas llamadas registran el estado de acceso del usuario como logged-in. Cuando el estado de acceso del usuario está configurado como logged-in, el RP que llama a FedCM realiza solicitudes al extremo de la lista de cuentas del IdP y muestra las cuentas disponibles al usuario en el diálogo de FedCM.

Para indicar que el usuario salió de todas sus cuentas, envía el encabezado HTTP Set-Login: logged-out en una navegación de nivel superior o una solicitud de subrecurso del mismo origen:

Set-Login: logged-out

Como alternativa, llama a la API de JavaScript navigator.login.setStatus('logged-out') desde el origen del IdP:

navigator.login.setStatus('logged-out');

Estas llamadas registran el estado de acceso del usuario como logged-out. Cuando el estado de acceso del usuario es logged-out, llamar a FedCM falla de forma silenciosa sin realizar una solicitud al extremo de la lista de cuentas del IdP.

El estado unknown se establece antes de que la AC envíe un indicador con la API de Login Status. Presentamos este estado para lograr una mejor transición, ya que es posible que un usuario ya haya accedido al IdP cuando enviamos esta API. Es posible que el IdP no tenga la oportunidad de indicar esto al navegador cuando se invoque FedCM por primera vez. En este caso, hacemos una solicitud al extremo de la lista de cuentas del IdP y actualizamos el estado según la respuesta del extremo de la lista de cuentas:

  • Si el extremo muestra una lista de cuentas activas, actualiza el estado a logged-in y abre el diálogo de FedCM para mostrar esas cuentas.
  • Si el extremo no muestra ninguna cuenta, actualiza el estado a logged-out y falla la llamada a FedCM.

¿Qué sucede si vence la sesión del usuario? Permite que el usuario acceda a través de un flujo de acceso dinámico.

Aunque el IdP sigue informando el estado de acceso del usuario al navegador, el estado podría estar desincronizado, por ejemplo, cuando vence la sesión. El navegador intenta enviar una solicitud con credenciales al extremo de la lista de cuentas cuando el estado de acceso es logged-in, pero el servidor no muestra ninguna cuenta porque la sesión ya no está disponible. En este caso, el navegador puede permitir que el usuario acceda al IdP de forma dinámica a través de una ventana de diálogo.

El diálogo de FedCM muestra un mensaje que sugiere que accedas, como se muestra en la siguiente imagen.

Un diálogo de FedCM que sugiere acceder al IdP
Un diálogo de FedCM que sugiere acceder al IdP.

Cuando el usuario hace clic en el botón Continuar, el navegador abre un diálogo para la página de acceso de la AC.

Ejemplo de diálogo.
Un ejemplo de diálogo que se muestra después de hacer clic en el botón de acceso al IdP.

La URL de la página de acceso se especifica con login_url como parte del archivo de configuración del IdP.

{
  "accounts_endpoint": "/auth/accounts",
  "client_metadata_endpoint": "/auth/metadata",
  "id_assertion_endpoint": "/auth/idtokens",
  "login_url": "/login"
  }
}

El diálogo es una ventana de navegador normal que tiene cookies propias. Lo que ocurra dentro del diálogo depende del IdP, y no hay controladores de ventana disponibles para realizar una solicitud de comunicación entre dominios a la página de la RP. Después de que el usuario acceda, el IdP debe hacer lo siguiente:

  • Envía el encabezado Set-Login: logged-in o llama a la API de navigator.login.setStatus("logged-in") para informarle al navegador que el usuario accedió.
  • Llama a IdentityProvider.close() para cerrar el diálogo.
Un usuario accede a un RP después de acceder al IdP con FedCM.
Un usuario accede a un RP después de acceder al IdP con FedCM.

Puedes probar el comportamiento de la API de Login Status en nuestra demo.

  1. Presiona el botón Go to the IdP and sign in.
  2. Accede con una cuenta arbitraria.
  3. Selecciona Sesión vencida en el menú desplegable Estado de la cuenta.
  4. Presiona el botón Actualizar información personal.
  5. Presiona el botón Visita el RP para probar FedCM.

Deberías poder observar el acceso a la IdP a través del comportamiento del módulo.

API de Error

Cuando Chrome envía una solicitud al extremo de afirmación de ID (por ejemplo, cuando un usuario hace clic en el botón Continuar como en la IU de FedCM o se activa la reautorización automática), es posible que la AC no pueda emitir un token por motivos legítimos. Por ejemplo, si el cliente no tiene autorización, el servidor no está disponible temporalmente, y así sucesivamente. Actualmente, Chrome falla la solicitud de forma silenciosa en caso de tales errores y solo notifica al RP rechazando la promesa.

Con la API de Error, Chrome notifica al usuario mostrándole una IU nativa con la información de error que proporciona el IdP.

Un diálogo de FedCM que muestra el mensaje de error después de que falla el intento de acceso del usuario. La cadena está asociada con el tipo de error.
Un diálogo de FedCM que muestra el mensaje de error después de que falla el intento de acceso del usuario. La cadena está asociada con el tipo de error.

API de HTTP del IdP

En la respuesta id_assertion_endpoint, la AC puede mostrar un token al navegador si se puede emitir a pedido. En esta propuesta, en caso de que no se pueda emitir un token, el IdP puede mostrar una respuesta de “error”, que tiene dos campos opcionales nuevos:

  1. code
  2. url
// id_assertion_endpoint response
{
  "error": {
     "code": "access_denied",
     "url": "https://idp.example/error?type=access_denied"
  }
}

En el caso del código, la AC puede elegir uno de los errores conocidos de la lista de errores especificada en OAuth 2.0 [invalid_request, unauthorized_client, access_denied, server_error y temporarily_unavailable] o usar cualquier cadena arbitraria. Si es el último caso, Chrome renderiza la IU de error con un mensaje de error genérico y pasa el código al RP.

En el caso de url, identifica una página web legible por humanos con información sobre el error para proporcionarles a los usuarios información adicional al respecto. Este campo es útil para los usuarios porque los navegadores no pueden proporcionar mensajes de error enriquecidos en una IU nativa. Por ejemplo, vínculos para los próximos pasos, información de contacto del servicio de atención al cliente, etcétera. Si un usuario quiere obtener más información sobre los detalles del error y cómo corregirlo, puede visitar la página proporcionada desde la IU del navegador. La URL debe ser del mismo sitio que el configURL de la IdP.

try {
  const cred = await navigator.credentials.get({
    identity: {
      providers: [
        {
          configURL: 'https://idp.example/manifest.json',
          clientId: '1234',
        },
      ],
    }
  });
} catch (e) {
  const code = e.code;
  const url = e.url;
}

API de Auto-Selected Flag

mediation: optional es el comportamiento de mediación de usuarios predeterminado en la API de Credential Management y activa la nueva autenticación automática cuando es posible. Sin embargo, es posible que la reautorización automática esté indisponible por motivos que solo el navegador conoce. Cuando no esté disponible, es posible que se le solicite al usuario que acceda con mediación del usuario explícita, que es un flujo con diferentes propiedades.

  • Desde la perspectiva de un llamador de la API, cuando recibe un token de ID, no tiene visibilidad sobre si fue el resultado de un flujo de reautorización automática. Eso les dificulta evaluar el rendimiento de la API y mejorar la UX según corresponda.
  • Desde la perspectiva del IdP, tampoco puede indicar si se produjo o no una reautorización automática para la evaluación del rendimiento. Además, si se involucró una mediación explícita del usuario podría ayudarlos a admitir más funciones relacionadas con la seguridad. Por ejemplo, algunos usuarios pueden preferir un nivel de seguridad más alto que requiera mediación explícita del usuario en la autenticación. Si un IdP recibe una solicitud de token sin esa mediación, podría controlar la solicitud de manera diferente. Por ejemplo, muestra un código de error para que el RP pueda volver a llamar a la API de FedCM con mediation: required.

Por lo tanto, proporcionar visibilidad del flujo de reautorización automática sería útil para los desarrolladores.

Con la API de Auto-selected Flag, Chrome comparte si se adquirió un permiso de usuario explícito presionando el botón Continuar como con la AC y la RP, cada vez que se produjo una reautorización automática o una mediación explícita. El uso compartido solo se produce después de que se otorga permiso al usuario para la comunicación del IdP/RP.

Uso compartido de IdP

Para compartir la información con el IdP después de que el usuario otorga permiso, Chrome incluye is_auto_selected=true en la solicitud POST que se envía a id_assertion_endpoint:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=Ct0D&disclosure_text_shown=true&is_auto_selected=true

Uso compartido de RP

El navegador puede compartir la información con el RP en isAutoSelected a través de IdentityCredential:

const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/manifest.json',
      clientId: '1234'
    }]
  }
});

if (cred.isAutoSelected !== undefined) {
  const isAutoSelected = cred.isAutoSelected;
}

Interactúa y comparte comentarios

Si tienes comentarios o tienes algún problema durante las pruebas, puedes compartirlos en crbug.com.

Foto de Girl with red hat en Unsplash