Publié le 8 septembre 2025
Les leaders de plusieurs secteurs comprennent l'importance de protéger la confidentialité tout en offrant une expérience utilisateur de qualité. Seznam s'engage à offrir une expérience utilisateur et une confidentialité sans compromis, et a intégré avec succès la gestion fédérée des identifiants (FedCM).
Entreprises qui bénéficient de FedCM
Les organisations de divers domaines intègrent FedCM à leurs solutions. Comme FedCM est conçu pour la gestion fédérée des identités, les fournisseurs d'identité (IdP) sont ses principaux bénéficiaires. Ils l'utilisent pour offrir une expérience de connexion améliorée. Les fournisseurs de services de commerce électronique et les fournisseurs de paiement, dont beaucoup agissent également en tant que fournisseurs d'identité, identifient également des opportunités d'améliorer l'expérience utilisateur grâce à FedCM.
Seznam
Seznam est une entreprise technologique et un fournisseur d'identité européen qui touche 90 % de la population tchèque. Il sert de plate-forme sociale, de connaissances et de contenus. Seznam a adopté FedCM pour permettre aux clients des boutiques en ligne opérant sur les plates-formes de ses partenaires de se connecter à l'aide de leur compte Seznam.
Grâce à FedCM, Seznam a enregistré une augmentation significative des taux de connexion des utilisateurs sur les réseaux partenaires, une expérience utilisateur améliorée et un flux d'identité cohérent, quelle que soit la disponibilité des cookies tiers.
Motivation
Seznam a choisi d'implémenter FedCM en raison de plusieurs avantages reconnus :
- FedCM est conçu pour l'utilisateur final, qui contrôle les informations fournies au fournisseur d'identité. Cela correspond à la vision de Seznam d'un environnement sécurisé et privé pour ses utilisateurs.
- FedCM est une fonctionnalité intégrée au navigateur et est compatible avec l'expérience de connexion existante de Seznam, qui utilise la norme OAuth 2.0.
- FedCM est une approche de la fédération d'identité axée sur la confidentialité. Par exemple, la visite de l'utilisateur sur la partie de confiance n'est partagée avec le fournisseur d'identité que si l'utilisateur se connecte. Cela correspond à la vision de Seznam d'une activité durable.
Détails de mise en œuvre
Seznam a implémenté FedCM en tant que couche au-dessus de sa solution OAuth existante. Dans cette architecture, le flux FedCM transmet de manière sécurisée un code d'autorisation OAuth du fournisseur d'identité aux parties de confiance.
Effort d'implémentation
Seznam a trouvé l'implémentation de FedCM simple et conforme à son approche existante. Ses recherches et son implémentation d'API ont duré un mois et ont nécessité deux développeurs. Il a fallu moins de deux mois pour mettre FedCM en production. Le processus était itératif, avec un temps considérable consacré à l'étude de l'API.
Défis
En tant que pionnier, Seznam a identifié plusieurs défis et fourni des commentaires précieux qui ont contribué à la maturation de l'API.
Compatibilité avec plusieurs fournisseurs d'identité
Seznam était intéressé par la compatibilité de FedCM avec plusieurs fournisseurs d'identité. Avec cette fonctionnalité, il visait à permettre aux utilisateurs de choisir entre Seznam ou des comptes Google sur les parties de confiance partenaires. Toutefois, lorsque Seznam a abordé pour la première fois son implémentation de FedCM, la fonctionnalité était à un stade précoce d'implémentation, et les développeurs devaient s'inscrire à un essai d'origine et utiliser un jeton pour activer la fonctionnalité pour les utilisateurs. Pour cette raison, Seznam a choisi d'attendre que la fonctionnalité soit disponible dans Chrome Stable.
La fonctionnalité est disponible à partir de Chrome 136, et les développeurs peuvent configurer la compatibilité avec plusieurs fournisseurs d'identité. Par exemple, pour prendre en charge les fournisseurs d'identité Seznam et Google, le fournisseur d'identité peut inclure les deux fournisseurs dans un seul appel get(), et la partie de confiance peut le faire indépendamment :
// 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 indique que cette fonctionnalité fera partie de sa solution. De plus, l'équipe FedCM implémente la compatibilité avec plusieurs SDK, avec la prise en charge de plusieurs appels get().
DNS privé
Seznam a rencontré un problème lié à sa configuration réseau lors de la phase de test. Son serveur de fournisseur d'identité de test résidait dans un réseau privé, accessible uniquement via un DNS privé. Cette configuration est courante pour les environnements de test et de développement internes avant l'exposition publique.
Toutefois, cette configuration pose un problème : comme un fichier well-known doit être diffusé à partir d'un eTLD+1, et qu'un domaine de développement privé n'est pas enregistré dans la liste des suffixes publics, le navigateur n'envoie pas de requêtes pour récupérer le fichier well-known hébergé sur le domaine de développement :
login.idp.example: exemple de domaine de production.idp.example/.well-known/web-identity: exemple de fichierwell-knownen production.login.dev.idp.example: exemple de domaine de développement.login.dev.idp.example/.well-known/web-identity: exemple de fichierwell-knowndans l'environnement de développement.
Lorsque l'implémentation de FedCM est hébergée sur un domaine privé, les requêtes du navigateur vers le fichier well-known génèrent l'erreur suivante :
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
Vous pouvez résoudre cette erreur en activant l'indicateur Chrome #fedcm-without-well-known-enforcement. Lorsque cet indicateur est activé, le navigateur ignore la récupération du fichier well-known à des fins de test. Découvrez comment activer les indicateurs de test dans Chrome.
Divulgation d'informations personnalisée
Seznam souhaitait également inclure des informations supplémentaires en plus de la conception initiale de l'interface utilisateur FedCM. La boîte de dialogue FedCM standard affiche un message fixe à l'utilisateur, indiquant que des données spécifiques (généralement l'image de profil, le nom et l'adresse e-mail de l'utilisateur) sont partagées avec la partie de confiance.
L'équipe FedCM a intégré les commentaires et étendu l'API pour permettre la personnalisation de la divulgation présentée à l'utilisateur. Par exemple, avec la fonctionnalité Continuer sur, le fournisseur d'identité peut rediriger l'utilisateur vers une page personnalisée pour demander des informations ou des autorisations supplémentaires. Les fonctionnalités "Paramètres personnalisés" et "Champs", compatibles à partir de Chrome 132, permettent une personnalisation plus poussée.
Validation de l'origine de la partie de confiance
Le serveur du fournisseur d'identité doit valider l'en-tête HTTP Origin sur une requête FedCM entrante pour s'assurer qu'elle correspond à l'origine que la partie de confiance a pré-enregistrée auprès du fournisseur d'identité. Cela garantit que la requête d'assertion d'identité FedCM ID provient d'une partie de confiance autorisée, et non d'un pirate informatique utilisant client_id.
Seznam présente un cas particulier : lorsque ses parties de confiance partenaires s'inscrivent auprès de Seznam, il ne demande pas les données d'origine de la partie de confiance. Cela signifie que l'origine de la partie de confiance ne peut pas être vérifiée.
L'intégration de FedCM par Seznam s'appuie sur une solution OAuth existante. Il a choisi une autre approche en validant à la fois le client_id et le client_secret de la partie de confiance pour s'assurer que la solution reste sécurisée sans vérifier l'origine.
Domaine du fournisseur d'identité visible par l'utilisateur
L'infrastructure d'authentification des utilisateurs de Seznam fonctionne principalement sur le domaine szn.cz, où sont hébergés les points de terminaison de fournisseur d'identité nécessaires pour FedCM. Toutefois, son identité d'entreprise principale et le domaine sous lequel les utilisateurs reconnaissent et font confiance à ses services sont seznam.cz.
La boîte de dialogue FedCM affiche le domaine d'origine réel des points de terminaison du fournisseur d'identité : szn.cz. Les utilisateurs qui connaissent la marque seznam.cz peuvent être confus et hésiter lorsqu'ils sont invités à se connecter avec le domaine szn.cz, moins familier, lors du processus de connexion.
À partir de Chrome 141, FedCM n'autorise pas l'affichage d'un domaine différent de celui qui héberge l'implémentation du fournisseur d'identité. Cette restriction est un choix de conception délibéré visant à garantir la transparence pour l'utilisateur. Toutefois, l'équipe FedCM reconnaît les défis que cette limitation peut créer et est en train de discuter des ajustements potentiels.
Impact
Grâce à l'API FedCM, Seznam peut désormais fournir des flux d'autorisation en un seul geste aux utilisateurs partenaires. Il a souligné les avantages de l'expérience utilisateur de FedCM par rapport à d'autres méthodes d'authentification.
Bien que Seznam ait constaté une augmentation significative de l'engagement des utilisateurs sur les sites Web qui sont passés à la connexion FedCM, il n'a pas effectué d'analyse complète pour isoler l'impact direct précis des autres facteurs. Avant l'intégration de FedCM, l'implémentation permettait les paiements en tant qu'invité à l'aide d'e-mails hachés avec consentement pour l'identification des utilisateurs. Le défi de la réalisation d'une telle analyse consistait à estimer si une conversion d'utilisateur pouvait être attribuée à FedCM ou si l'utilisateur aurait effectué un achat en tant qu'invité. L'hypothèse de Seznam suggère que la facilité d'utilisation améliorée de FedCM pourrait avoir contribué à ce taux de conversion plus élevé.
Conclusion
Seznam a implémenté FedCM avec succès, en fournissant un flux d'autorisation alternatif en plus de sa solution OAuth existante. Bien que Seznam ait rencontré des difficultés liées à la compatibilité avec les fournisseurs d'identité, aux configurations DNS privées, à la personnalisation du texte de divulgation, à la validation de l'origine de la partie de confiance et à l'affichage du domaine visible par l'utilisateur, l'API a évolué depuis son implémentation. L'équipe FedCM a intégré les commentaires de Seznam et d'autres pionniers, ce qui a permis de créer de meilleurs outils pour relever ces défis. À l'étape suivante, Seznam prévoit d'implémenter la compatibilité de FedCM avec plusieurs fournisseurs d'identité.