Los líderes de la industria de varios sectores comprenden la importancia de proteger la privacidad y, al mismo tiempo, brindar una excelente experiencia a todos sus usuarios. Seznam, que se dedica a brindar una experiencia del usuario y privacidad sin concesiones, integró con éxito Federated Credential Management (FedCM).
Perfiles objetivo: Empresas que se benefician con FedCM
Organizaciones de diversos dominios integraron FedCM en sus soluciones. Dado el diseño de FedCM para la administración de identidades federadas, los proveedores de identidad (IdP) son sus principales beneficiarios, ya que lo usan para ofrecer una experiencia de acceso mejorada. 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 identificaron oportunidades para mejorar la experiencia del usuario a través de la implementación 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.

Con FedCM, Seznam logró un aumento notable en los porcentajes de acceso de los usuarios en las redes de sus socios, una experiencia del usuario mejorada y un flujo de identidad coherente, independientemente de la disponibilidad de cookies de terceros.
Motivación
La decisión de Seznam de implementar FedCM se basó en varias ventajas que identificaron:
- FedCM se diseñó pensando en el usuario final, lo que le permite controlar 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 que es compatible con la experiencia de acceso existente de Seznam, que usa el estándar OAuth 2.0.
- FedCM se diseñó como un enfoque centrado en la privacidad para la federación de identidades. Por ejemplo, el hecho de que el usuario haya visitado la parte que confía (RP) solo se comparte con el IdP si el usuario elige acceder. 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, se utiliza el flujo de FedCM para transmitir de forma segura un código de autorización de OAuth desde el IdP a los RP.

Esfuerzo de implementación
Seznam destacó que la implementación de FedCM fue sencilla y se alineó con su enfoque existente. Su investigación e implementación de la API abarcó un mes y requirió el esfuerzo de dos desarrolladores. Les llevó menos de dos meses llevar FedCM a producción. El proceso fue iterativo y se dedicó una cantidad considerable de tiempo a estudiar cuidadosamente 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, el objetivo era permitir que los usuarios eligieran entre las cuentas de Seznam o de Google en los RP de sus socios. Sin embargo, cuando Seznam abordó por primera vez su implementación de FedCM, la función se encontraba en una etapa inicial de implementación, y los desarrolladores debían registrarse para una prueba de origen y usar un token para habilitar la función para sus usuarios. Por este motivo, Seznam decidió esperar a que la función se lanzara en Chrome estable.
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 también puede hacerlo de forma independiente:
// Executed on the RP's side:
const credential = await navigator.credentials.get({
identity: {
providers: [
{
// IdP1: Seznam's config file URL
configURL: 'https://szn.cz/.well-known/web-identity',
clientId: '123',
},
{
// Also allow Google Sign-in
configURL: 'https://accounts.google.com/gsi/fedcm.json',
clientId: '456',
},
],
},
});
Seznam indicó 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 múltiples llamadas a get()
.
DNS privado
Seznam tuvo un problema relacionado con la configuración de su red durante la fase de pruebas. Su servidor de 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 internos de desarrollo y pruebas antes de que los servicios se expongan públicamente.
Sin embargo, esta configuración genera 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
: Ejemplo de archivo conocido en producción.login.dev.idp.example
: Es un ejemplo de dominio de desarrollo.login.dev.idp.example/.well-known/web-identity
: Ejemplo de archivo conocido 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
Este error se puede solucionar habilitando la marca #fedcm-without-well-known-enforcement
de Chrome. Cuando esta marca está habilitada, el navegador omite la recuperación del archivo well-known
con fines de prueba. Obtén más información para habilitar las marcas de prueba en Chrome.
Divulgación de información personalizada
Seznam también compartió que 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 Parámetros personalizados y Campos, compatibles con Chrome 132, permiten una mayor personalización.

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 previó registrar 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 una situación de caso límite: cuando sus RP socios se registran en Seznam, no solicitan 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. Tomaron 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 necesidad de 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
, que es donde 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
.
En el diálogo de FedCM, se muestra el dominio de origen real de los extremos del IdP, que, en este caso, es 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
menos conocido 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 puede 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 de sus socios. Destacaron los beneficios que proporciona 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 hash con consentimiento para la identificación del usuario. El desafío para 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 que ofrece 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 los desarrolladores de Seznam enfrentaron 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 resolver estos desafíos. Como siguiente paso, Seznam planea implementar la compatibilidad de FedCM con varios proveedores de identidad.