Autenticación de usuarios privada y sin problemas con FedCM: el enfoque de Seznam

Natalia Markoborodova
Natalia Markoborodova

Publicado el 8 de septiembre de 2025

Los líderes de la industria en varios sectores comprenden la importancia de proteger la privacidad y, al mismo tiempo, brindar una excelente experiencia del usuario. Seznam se dedica a brindar una experiencia del usuario y privacidad sin concesiones, y logró integrar Federated Credential Management (FedCM).

Empresas que se benefician con FedCM

Las organizaciones de diversos dominios integran FedCM en sus soluciones. Dado que FedCM está diseñado para la administración de identidades federadas, los proveedores de identidad (IdP) son sus principales beneficiarios. La usan para ofrecer una mejor experiencia de acceso. Los proveedores de servicios de comercio electrónico y los proveedores de pagos, muchos de los cuales también actúan como proveedores de identidad, también identifican oportunidades para mejorar la experiencia del usuario a través de FedCM.

Seznam

Seznam es una empresa de tecnología y proveedor de identidad europeo que llega al 90% de la población checa. Funciona como un centro social, de conocimiento y de contenido. Seznam adoptó FedCM para permitir que los clientes de las tiendas en línea que operan en las plataformas de sus socios accedan con su cuenta de Seznam.

Cuadro de diálogo de FedCM en eshop.starkl.com, en el que se le solicita a un usuario que acceda con su cuenta de Seznam.
Diálogo de FedCM que le solicita a un usuario que acceda con Seznam en el sitio de un socio.

Con FedCM, Seznam logró un aumento significativo en las tasas de acceso de los usuarios en las redes de socios, una mejor experiencia del usuario y un flujo de identidad coherente, independientemente de la disponibilidad de las cookies de terceros.

Motivación

Seznam decidió implementar FedCM debido a varias ventajas reconocidas:

  • FedCM se diseñó pensando en el usuario final, lo que les brinda a los usuarios control sobre la información que se proporciona al IdP. Esto se alinea con la visión de Seznam de un entorno seguro y privado para sus usuarios.
  • FedCM es una función integrada del navegador y es compatible con la experiencia de acceso existente de Seznam, que usa el estándar OAuth 2.0.
  • FedCM es un enfoque centrado en la privacidad para la federación de identidades. Por ejemplo, la visita del usuario a la parte que confía (RP) solo se comparte con el IdP si el usuario accede. Esto se alinea con la visión de Seznam sobre los negocios sustentables.

Detalles de implementación

Seznam implementó FedCM como una capa sobre su solución de OAuth existente. En esta arquitectura, el flujo de FedCM transmite de forma segura un código de autorización de OAuth desde el IdP a los RP.

Flujo de FedCM, que muestra el token de FedCM intercambiado por un código de autorización de OAuth del lado del IdP
Flujo de FedCM integrado con OAuth. Consulta el código del diagrama.

Esfuerzo de implementación

Seznam descubrió que la implementación de FedCM era sencilla y se alineaba con su enfoque existente. Su investigación y la implementación de la API abarcaron un mes y requirieron dos desarrolladores. Llevó menos de dos meses llevar FedCM a producción. El proceso fue iterativo y se dedicó una cantidad considerable de tiempo al estudio de la API.

Desafíos

Como usuario pionero, Seznam identificó varios desafíos y proporcionó comentarios valiosos que ayudaron a madurar la API.

Compatibilidad con varios proveedores de identidad

A Seznam le interesaba la compatibilidad de FedCM con varios proveedores de identidad. Con esta función, se buscaba permitir que los usuarios eligieran entre las Cuentas de Seznam o de Google en los RP de socios. Sin embargo, cuando Seznam se acercó por primera vez a su implementación de FedCM, la función se encontraba en una etapa de implementación inicial, y los desarrolladores debían registrarse para una prueba de origen y usar un token para habilitar la función para los usuarios. Por este motivo, Seznam decidió esperar a que la función se lanzara en la versión estable de Chrome.

La función está disponible a partir de Chrome 136, y los desarrolladores pueden configurar la compatibilidad con varios proveedores de identidad. Por ejemplo, para admitir los proveedores de identidad de Seznam y Google, el IdP puede incluir los dos proveedores en una sola llamada a get(), y el RP puede hacerlo de forma independiente:

  // Executed on the RP's side:
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // IdP1: Seznam config file URL
            configURL: 'https://szn.cz/.well-known/web-identity',
            clientId: '123',
          },
          {
            // Allow Google Sign-in
            configURL: 'https://accounts.google.com/gsi/fedcm.json',
            clientId: '456',
          },
        ],
      },
    });

Seznam indica que esta función formará parte de su solución. Además, el equipo de FedCM está implementando la compatibilidad con varios SDKs, con compatibilidad para varias llamadas a get().

DNS privado

Durante la fase de pruebas, Seznam tuvo un problema relacionado con la configuración de su red. Su servidor IdP de prueba residía en una red privada, a la que solo se podía acceder a través de un DNS privado. Esta configuración es común para los entornos de desarrollo y pruebas internos antes de la exposición pública.

Sin embargo, esta configuración plantea un desafío: dado que un archivo well-known debe publicarse desde un eTLD+1, y un dominio de desarrollo privado no está registrado en la Lista de sufijos públicos, el navegador no enviará solicitudes para recuperar el archivo well-known alojado en el dominio de desarrollo:

  • login.idp.example: Es un ejemplo de dominio de producción.
  • idp.example/.well-known/web-identity: Archivo de ejemplo well-known en producción.
  • login.dev.idp.example: Es un ejemplo de dominio de desarrollo.
  • login.dev.idp.example/.well-known/web-identity: Archivo well-known de ejemplo en el entorno de desarrollo.

Cuando la implementación de FedCM se aloja en un dominio privado, las solicitudes del navegador al archivo well-known generan este error:

The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED

Para resolver este error, habilita la marca #fedcm-without-well-known-enforcement de Chrome. Cuando esta marca está habilitada, el navegador omite la recuperación del archivo well-known para fines de prueba. Obtén más información para habilitar funciones experimentales en Chrome.

Divulgación de información personalizada

Seznam también quería incluir información adicional junto con el diseño inicial de la IU de FedCM. El diálogo estándar de FedCM muestra un mensaje fijo al usuario en el que se indica que se comparten datos específicos (por lo general, la imagen de perfil, el nombre y la dirección de correo electrónico del usuario) con el RP.

El equipo de FedCM incorporó los comentarios y extendió la API para permitir la personalización de la divulgación que se presenta al usuario. Por ejemplo, con la función Continuar en, el IdP puede redireccionar al usuario a una página personalizada para solicitar información o permisos adicionales. Las funciones de parámetros personalizados y campos, compatibles a partir de Chrome 132, permiten una mayor personalización.

Página del IdP que muestra que un usuario debe otorgar permisos adicionales para continuar con el registro de FedCM, como ver y descargar archivos de Drive y eventos de calendario.
El usuario puede revisar y otorgar permisos adicionales que el RP pasa al extremo de aserción de ID con la API de "Parameters".

Validación del origen del usuario autenticado

El servidor del IdP debe validar el encabezado HTTP Origin en una solicitud de FedCM entrante para garantizar que la solicitud coincida con el origen que el RP pre registró con el IdP. Esto garantiza que la solicitud de aserción de ID de FedCM provenga de un RP autorizado y no de un atacante que use client_id.

Seznam tiene un caso límite: cuando sus RP socios se registran en Seznam, no solicita los datos de origen del RP. Esto significa que no se puede verificar el origen del RP.

La integración de FedCM de Seznam se basa en una solución de OAuth existente. Tomó la ruta alternativa de validar tanto el client_id como el client_secret del RP para garantizar que la solución siguiera siendo segura sin verificar el origen.

Dominio visible para el usuario del proveedor de identidad

La infraestructura de autenticación de usuarios de Seznam opera principalmente en el dominio szn.cz, en el que se alojan los extremos de IdP necesarios para FedCM. Sin embargo, su identidad corporativa principal y el dominio bajo el cual los usuarios reconocen y confían ampliamente en sus servicios son seznam.cz.

El diálogo de FedCM muestra el dominio de origen real de los extremos del IdP: szn.cz. Los usuarios que conocen la marca seznam.cz pueden confundirse y dudar cuando se les solicite que accedan con el dominio szn.cz, que les resulta menos familiar, durante el proceso de acceso.

A partir de Chrome 141, FedCM no permite mostrar un dominio diferente del que aloja la implementación del IdP. Esta restricción es una elección de diseño deliberada que tiene como objetivo garantizar la transparencia para el usuario. Sin embargo, el equipo de FedCM reconoce los desafíos que podría generar esta limitación y está analizando posibles ajustes.

Impacto

Con la API de FedCM, Seznam ahora puede proporcionar flujos de autorización con un solo toque a los usuarios socios. Se destacaron los beneficios de la UX de FedCM en comparación con otros métodos de autenticación.

Si bien Seznam observó un aumento significativo en la participación de los usuarios en los sitios web que hicieron la transición al acceso con FedCM, no realizó un análisis integral para aislar el impacto directo preciso de otros factores. Antes de la integración de FedCM, la implementación permitía la confirmación de compra como invitado con correos electrónicos codificados con hash con consentimiento para la identificación del usuario. El desafío de realizar este análisis fue estimar si una conversión del usuario se podía atribuir a FedCM o si el usuario habría completado una compra con la confirmación de compra como invitado. La hipótesis de Seznam sugiere que la mayor facilidad de uso de FedCM podría haber contribuido a este mayor porcentaje de conversiones.

Conclusión

Seznam implementó FedCM con éxito, lo que proporcionó un flujo de autorización alternativo junto con su solución de OAuth existente. Si bien Seznam enfrentó algunos desafíos relacionados con la compatibilidad con proveedores de identidad, la configuración de DNS privados, la personalización del texto de divulgación, la validación del origen de la parte que confía y la visualización del dominio para el usuario, la API ha madurado desde su implementación. El equipo de FedCM incorporó los comentarios de Seznam y otros usuarios pioneros, lo que permitió crear mejores herramientas para abordar estos desafíos. Como siguiente paso, Seznam planea implementar la compatibilidad de FedCM con varios proveedores de identidad.