Les leaders de plusieurs secteurs comprennent l'importance de protéger la confidentialité tout en offrant une expérience de qualité à tous leurs utilisateurs. Seznam, qui s'engage à offrir une expérience utilisateur et une confidentialité sans compromis, a réussi à intégrer Federated Credential Management (FedCM).
Profils cibles : entreprises bénéficiant de FedCM
Des entreprises de différents secteurs ont intégré 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, car 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é, ont également identifié des opportunités d'améliorer l'expérience utilisateur grâce à l'implémentation de 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.
Grâce à FedCM, Seznam a constaté une augmentation notable du taux de connexion des utilisateurs sur les réseaux de ses partenaires, une amélioration de l'expérience utilisateur 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 qu'il a identifiés :
- 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 compatible avec l'expérience de connexion existante de Seznam, qui utilise la norme OAuth 2.0.
- FedCM est conçu pour être une approche de fédération d'identité axée sur la confidentialité. Par exemple, le fait que l'utilisateur ait visité la partie de confiance (RP, Relying Party) n'est partagé avec l'IdP que si l'utilisateur choisit de se connecter. Cela correspond à la vision de Seznam sur les activités durables.
Détails de mise en œuvre
Seznam a implémenté FedCM comme couche au-dessus de sa solution OAuth existante. Dans cette architecture, le flux FedCM est utilisé pour transmettre de manière sécurisée un code d'autorisation OAuth du fournisseur d'identité aux RP.
Effort d'implémentation
Seznam a souligné que l'implémentation de FedCM était simple et s'alignait sur leur approche existante. Leur recherche et l'implémentation de l'API ont duré un mois et ont nécessité l'effort de deux développeurs. Il leur a fallu moins de deux mois pour mettre FedCM en production. Le processus était itératif, avec un temps considérable consacré à l'étude approfondie 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é. Grâce à cette fonctionnalité, ils souhaitaient permettre aux utilisateurs de choisir entre un compte Seznam ou Google sur les RP de leurs partenaires. Toutefois, lorsque Seznam a abordé pour la première fois l'implémentation de FedCM, la fonctionnalité était à un stade précoce de son implémentation. Les développeurs devaient s'inscrire à un test d'origine et utiliser un jeton pour activer la fonctionnalité pour leurs 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 compatibilité avec 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 également le faire de manière indépendante :
// 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 a indiqué que cette fonctionnalité ferait 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. Le serveur IdP de test de l'entreprise 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 que les services ne soient exposés publiquement.
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'enverra 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 connu en production.login.dev.idp.example: exemple de domaine de développement.login.dev.idp.example/.well-known/web-identity: exemple de fichier connu dans l'environnement de développement.
Lorsque l'implémentation FedCM est hébergée sur un domaine privé, les requêtes du navigateur envoyées 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
Pour résoudre cette erreur, activez l'option #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 a également indiqué qu'il souhaitait inclure des informations supplémentaires en plus 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 de la divulgation présentée à l'utilisateur. Par exemple, avec la fonctionnalité Continuer sur, l'IdP 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, disponibles à partir de Chrome 132, permettent une personnalisation plus poussée.
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 partenaires RP s'inscrivent auprès de Seznam, ils ne demandent pas les données d'origine du RP. Cela signifie que l'origine du RP ne peut pas être vérifiée.
L'intégration FedCM de Seznam repose sur une solution OAuth existante. Ils ont choisi une autre méthode pour valider les client_id et client_secret du RP afin de s'assurer que la solution restait sécurisée sans avoir à 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, leur identité d'entreprise principale et le domaine sous lequel les utilisateurs reconnaissent et font confiance à leurs 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 dans le cas présent).
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, moins familier, lors du processus de connexion.
Depuis 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 l'utilisateur. 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 de ses partenaires. Ils ont 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, l'entreprise 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 identifier les utilisateurs. Le défi pour effectuer une telle analyse était d'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 offerte par FedCM pourrait avoir contribué à ce taux de conversion plus élevé.
Conclusion
Seznam a implémenté FedCM avec succès, en proposant un autre flux d'autorisation en plus de sa solution OAuth existante. Bien que les développeurs de Seznam aient rencontré des difficultés liées à la prise en charge du fournisseur 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 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 prise en charge de FedCM pour plusieurs fournisseurs d'identité.