Authentification utilisateur fluide et privée avec FedCM : l'approche de Seznam

Natalia Markoborodova
Natalia Markoborodova

Publié le 8 septembre 2025

Les leaders de différents 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 Federated Credential Management (FedCM).

Entreprises qui bénéficient de FedCM

Des organisations de différents domaines intègrent FedCM à leurs solutions. Étant donné que FedCM est conçu pour la gestion des identités fédérées, 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 d'e-commerce et de services 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éens qui touchent 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.

Boîte de dialogue FedCM sur eshop.starkl.com, invitant un utilisateur à se connecter avec son compte Seznam.
Boîte de dialogue FedCM invitant un utilisateur à se connecter avec Seznam sur le site d'un partenaire.

Grâce à FedCM, Seznam a considérablement augmenté le taux de connexion des utilisateurs sur les réseaux partenaires, amélioré l'expérience utilisateur et obtenu 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 peut ainsi contrôler les informations fournies à l'IdP. Cela correspond à la vision de Seznam, qui souhaite offrir un environnement sécurisé et privé à ses utilisateurs.
  • FedCM est une fonctionnalité de navigateur intégrée et est compatible avec l'expérience de connexion existante de Seznam, qui utilise la norme OAuth 2.0.
  • FedCM est une approche axée sur la confidentialité pour la fédération d'identité. Par exemple, la visite de l'utilisateur à la partie de confiance (RP) n'est partagée avec l'IdP que si l'utilisateur se connecte. Cela correspond à la vision de Seznam sur les activités durables.

Détails de mise en œuvre

Seznam a implémenté FedCM comme une 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 de l'IdP aux RP.

Flux FedCM montrant le jeton FedCM échangé contre un code d'autorisation OAuth côté IdP
Flux FedCM intégré à OAuth. Consultez le code du diagramme.

Effort d'implémentation

Seznam a trouvé l'implémentation de FedCM simple et conforme à son approche existante. La recherche et l'implémentation de l'API ont duré un mois et ont nécessité deux développeurs. Il a fallu moins de deux mois pour déployer 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 de précieux commentaires qui ont contribué à la maturation de l'API.

Compatibilité avec plusieurs fournisseurs d'identité

Seznam s'intéressait à la compatibilité de FedCM avec plusieurs fournisseurs d'identité. Cette fonctionnalité visait à permettre aux utilisateurs de choisir entre les comptes Seznam et Google sur les RP partenaires. Toutefois, lorsque Seznam a abordé l'implémentation de FedCM pour la première fois, la fonctionnalité était à un stade précoce d'implémentation. Les développeurs devaient s'inscrire à un test d'origine et utiliser un jeton pour activer la fonctionnalité pour les utilisateurs. C'est pourquoi Seznam a choisi d'attendre que la fonctionnalité soit disponible dans la version stable de Chrome.

Cette fonctionnalité est disponible à partir de Chrome 136. Les développeurs peuvent configurer la prise en charge de plusieurs fournisseurs d'identité. Par exemple, pour prendre en charge les fournisseurs d'identité Seznam et Google, l'IdP peut inclure les deux fournisseurs dans un seul appel get(), et le RP 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. L'équipe FedCM implémente également la compatibilité avec plusieurs SDK, avec la prise en charge de plusieurs appels get().

DNS privé

Seznam a rencontré un problème lié à la configuration de son réseau lors de la phase de test. Son serveur IdP 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 de 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 fichier well-known en production.
  • login.dev.idp.example : exemple de domaine de développement.
  • login.dev.idp.example/.well-known/web-identity : exemple de fichier well-known dans l'environnement de développement.

Lorsque l'implémentation FedCM est hébergée sur un domaine privé, les requêtes du navigateur au fichier well-known génèrent cette erreur :

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

Vous pouvez résoudre cette erreur en activant le flag #fedcm-without-well-known-enforcement de Chrome. 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 à côté de la conception initiale de l'UI FedCM. La boîte de dialogue FedCM standard affiche un message fixe à l'utilisateur, indiquant que des données spécifiques (généralement la photo de profil, le nom et l'adresse e-mail de l'utilisateur) sont partagées avec le RP.

L'équipe FedCM a intégré les commentaires et étendu l'API pour permettre la personnalisation des informations présentées à l'utilisateur. Par exemple, avec la fonctionnalité Continuer sur, l'IdP peut rediriger l'utilisateur vers une page personnalisée pour lui demander des informations ou des autorisations supplémentaires. Les fonctionnalités Paramètres personnalisés et Champs, disponibles à partir de Chrome 132, permettent une personnalisation plus poussée.

Page de l'IdP indiquant qu'un utilisateur doit accorder des autorisations supplémentaires pour continuer l'inscription FedCM, comme l'affichage et le téléchargement de fichiers Drive et d'événements d'agenda.
L'utilisateur peut examiner et accorder des autorisations supplémentaires transmises par le RP au point de terminaison d'assertion d'identité avec l'API Parameters.

Validation de l'origine de la partie de confiance

Le serveur IdP doit valider l'en-tête HTTP Origin sur une requête FedCM entrante pour s'assurer que la requête correspond à l'origine que le RP a préenregistrée auprès de l'IdP. Cela permet de s'assurer que la demande d'assertion d'identité FedCM provient d'une RP autorisée et non d'un pirate informatique utilisant client_id.

Seznam présente un cas particulier : lorsque ses RP partenaires s'enregistrent auprès de Seznam, ils ne demandent pas les données d'origine des RP. Cela signifie que l'origine du RP ne peut pas être vérifiée.

L'intégration FedCM de Seznam s'appuie sur une solution OAuth existante. Il a choisi une autre voie en validant les client_id et client_secret du fournisseur d'identité pour s'assurer que la solution restait sécurisée sans vérifier l'origine.

Domaine visible par l'utilisateur du fournisseur d'identité

L'infrastructure d'authentification des utilisateurs de Seznam fonctionne principalement sur le domaine szn.cz, où sont hébergés les points de terminaison IdP 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 IdP : szn.cz. Les utilisateurs qui connaissent la marque seznam.cz peuvent être déroutés et hésiter lorsqu'ils sont invités à se connecter avec le domaine szn.cz, qui leur est moins familier.

À partir de Chrome 141, FedCM n'autorise pas l'affichage d'un domaine différent de celui hébergeant l'implémentation IdP. Cette restriction est un choix de conception délibéré visant à assurer la transparence pour les utilisateurs. Toutefois, l'équipe FedCM reconnaît les difficultés que cette limitation peut créer et discute des ajustements potentiels.

Impact

Grâce à l'API FedCM, Seznam peut désormais proposer des flux d'autorisation en un clic aux utilisateurs partenaires. Il a souligné les avantages de l'UX de FedCM par rapport aux 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 aux clients de passer à la caisse en tant qu'invités à l'aide d'adresses e-mail hachées consenties pour l'identification des utilisateurs. La difficulté de cette analyse résidait dans l'estimation de la possibilité d'attribuer une conversion d'utilisateur à 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, ce qui lui a permis de proposer un autre flux d'autorisation 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 pour les utilisateurs, l'API a évolué depuis son implémentation. L'équipe FedCM a intégré les commentaires de Seznam et d'autres utilisateurs précoces, ce qui a permis de développer de meilleurs outils pour relever ces défis. Seznam prévoit ensuite d'implémenter la compatibilité de FedCM avec plusieurs fournisseurs d'identité.