Défragmenter les connexions multidomaines

Eiji Kitamura

Les architectures d'entreprise modernes couvrent souvent plusieurs domaines distincts. Les organisations gèrent des environnements dédiés pour différentes fonctionnalités, telles que brand.example pour le marketing, service-app.example pour le produit principal et support-portal.example pour le service client. Idéalement, vous souhaitez offrir une expérience d'authentification unique et unifiée lorsque les utilisateurs naviguent entre ces propriétés. Toutefois, les équipes d'ingénierie intègrent souvent ces domaines à l'aide de techniques ad hoc qui entraînent une fragmentation. Cela perturbe la gestion intégrée des identifiants du navigateur en interrompant les flux de saisie automatique du gestionnaire de mots de passe et en bloquant l'adoption des clés d'accès.

Si le même compte couvre plusieurs domaines, l'utilisateur doit reconnaître que les domaines appartiennent à la même organisation et fournir les mêmes identifiants lors de la connexion. Dans le pire des cas, l'utilisateur crée un compte en double ou communique son mot de passe à un site Web d'hameçonnage.

Découvrez comment utiliser des normes et des solutions architecturales (telles que les métadonnées, les iFrame inter-origines, la fédération d'identité et la consolidation des sous-domaines) pour résoudre la fragmentation de l'identité interdomaine et offrir un parcours utilisateur fluide.

Solutions courantes

Les organisations utilisent plusieurs techniques établies pour maintenir un parcours interdomaine. Bien que ces méthodes soient courantes, elles se heurtent à des obstacles structurels, car les navigateurs appliquent des limites de confidentialité et des normes de sécurité plus strictes.

Requêtes d'extraction CORS

Lorsque les domaines fonctionnent indépendamment, les interfaces utilisateur s'appuient fréquemment sur des requêtes inter-origines fetch() dirigées vers une API d'authentification centralisée, qui peut être autorisée de manière sécurisée à l'aide de Cross-Origin Resource Sharing (CORS). Étant donné que les navigateurs bloquent ou limitent souvent les cookies intersites, les développeurs peuvent concevoir explicitement ces API pour qu'elles renvoient des jetons d'authentification, tels que des jetons Web JSON (JWT) dans des charges utiles JSON, plutôt que de s'appuyer sur des en-têtes Set-Cookie.

Partage de la base de données de comptes

Pour unifier l'identité sur le backend sans intégrations frontend complexes, vous pouvez centraliser votre magasin de données utilisateur. Bien que plusieurs domaines s'authentifient par rapport à la même base de données, leurs expériences de connexion frontend restent distinctes. Les utilisateurs sont alors obligés de se souvenir des domaines pour lesquels ils ont utilisé les mêmes identifiants, ce qui nuit à l'expérience utilisateur.

Problèmes liés aux connexions disjointes

Bien que les solutions techniques puissent atteindre une fonctionnalité de base, elles ne permettent pas d'offrir un parcours fluide. Les flux de connexion disjoints introduisent des points de friction qui compromettent à la fois l'utilisabilité et la sécurité.

Fragmentation du gestionnaire de mots de passe

Le point de friction le plus élevé est la perturbation des gestionnaires de mots de passe. Les gestionnaires de mots de passe lient les identifiants stockés à l'origine spécifique où ils sont enregistrés. Cela empêche le navigateur de proposer la saisie automatique sur différents domaines, même s'ils appartiennent à la même organisation.

Lorsqu'un utilisateur passe d'un domaine avec des identifiants enregistrés à un nouveau domaine de votre organisation, le gestionnaire de mots de passe ne reconnaît pas la relation et ne déclenche pas l'invite de saisie automatique. Cela crée une friction de saisie manuelle. Les utilisateurs doivent rechercher leurs identifiants, réinitialiser leur mot de passe ou créer un compte en double.

Étant donné que le gestionnaire de mots de passe s'avère peu fiable sur ces propriétés, les utilisateurs peuvent abandonner les outils pour ces sites. Au lieu de cela, ils créent souvent des mots de passe faibles et mémorisables à réutiliser ailleurs, ce qui dégrade la sécurité globale de votre organisation.

Passerelle d'hameçonnage

Cette perturbation fonctionne comme une passerelle d'hameçonnage. Le refus d'un gestionnaire de mots de passe de remplir automatiquement un domaine non reconnu est un mécanisme de défense principal. En obligeant les utilisateurs à saisir manuellement leurs identifiants sur différentes URL, vous les entraînez involontairement à être victimes d'attaques d'hameçonnage.

Roadblock lié aux clés d'accès

La friction augmente lorsque vous utilisez des clés d'accès. L'architecture de sécurité de base de WebAuthn lie cryptographiquement les clés d'accès à un ID de partie de confiance (RP ID) spécifié.

Cela crée un "piège d'ID RP". Une clé d'accès enregistrée sur brand.example est inutilisable sur service-app.example, car le navigateur refuse l'accès interdomaine. Pour éviter d'inviter les utilisateurs à enregistrer des clés d'accès distinctes pour chaque site, vous devez consolider ces propriétés en un seul ID RP.

Approches recommandées

Pour établir la continuité de l'identité, vous devez abandonner les intégrations de connexion ad hoc et adopter des normes architecturales reconnues :

• Utiliser des fichiers de configuration de métadonnées: hébergez des fichiers de métadonnées tels que Digital Asset Links et Related Origin Requests, pour établir une chaîne de confiance cryptographique. Cela permet de partager facilement les identifiants et les clés d'accès sur différents domaines et applications mobiles. Cette approche est une solution silencieuse et peu coûteuse pour la fragmentation de l'identité, qui ne nécessite pas de réarchitecture complexe de l'infrastructure Web existante.
• Utiliser des iFrame inter-origines : intégrez une origine d'authentification centralisée en tant qu'iFrame dans une partie de confiance pour relier les identifiants et les clés d'accès enregistrés sur différents sites. Cette approche utilise la règle d'autorisation et les cookies partitionnés pour offrir une expérience de connexion fluide et contextuelle, tout en maintenant des limites de sécurité strictes via CSP et la messagerie inter-documents.
• Suivre la fédération d'identité standard: Adoptez des protocoles standards du secteur tels qu'OpenID Connect pour centraliser l'authentification sur un domaine de fournisseur d'identité dédié. Cela formalise le parcours de connexion via des redirections sécurisées, en remplaçant les intégrations fragiles par une solution propriétaire fiable et évolutive.
• Consolider les sous-domaines : passez à des sous-domaines sous une racine commune. Cela permet de partager facilement les sessions via des cookies génériques et d'assurer la continuité des clés d'accès sur l'ensemble du domaine enregistrable. De nombreux gestionnaires de mots de passe peuvent reconnaître le domaine racine partagé et suggérer automatiquement les identifiants enregistrés sur les sous-domaines associés.

Utiliser des fichiers de configuration de métadonnées

L'un des principaux défis de l'identité interdomaine est la fragmentation des identifiants enregistrés. Les gestionnaires de mots de passe traitent les différents domaines et applications comme des entités complètement isolées, ce qui les empêche de remplir automatiquement les identifiants enregistrés sur une propriété dans une autre.

Pour résoudre la fragmentation, vous pouvez configurer le comportement des gestionnaires de mots de passe au lieu de modifier la structure de votre site Web. En hébergeant des fichiers de configuration de métadonnées spécifiques, les organisations peuvent affirmer de manière cryptographique que des domaines et des applications disparates appartiennent à la même organisation. Cela permet aux systèmes d'exploitation, aux navigateurs et aux gestionnaires de mots de passe de reconnaître cette relation et de relier automatiquement le contexte d'identité, en partageant les mots de passe et les clés d'accès sur vos propriétés. Cette approche est également nécessaire pour partager des mots de passe et des clés d'accès basés sur le Web avec des applications mobiles, même si vos domaines Web sont consolidés.

Utilisez deux fichiers de configuration différents pour vous assurer de couvrir différentes plates-formes et écosystèmes :

• Gestionnaire de mots de passe Google sur Android et Chrome : hébergez un fichier JSON Digital Asset Links (DAL) sur /.well-known/assetlinks.json pour établir une relation de confiance vérifiable entre les applications et les sites Web associés d'une organisation. Cette confiance permet d'utiliser des liens profonds dans les applications et le partage continu d'identifiants, où les mots de passe enregistrés sur le Web sont automatiquement remplis sur les sites Web associés (bien que le partage de clés d'accès sur plusieurs domaines Web nécessite toujours des requêtes d'origine associée). Pour en savoir plus, consultez le guide sur le partage continu d'identifiants.

• Mots de passe Apple sur iOS et Safari : hébergez un fichier AASA (Apple App Site Association) sur /.well-known/apple-app-site-association pour établir la chaîne de confiance cryptographique nécessaire pour relier les états des mots de passe Apple entre les applications iOS et Safari. Pour prendre en charge les écosystèmes tiers, vous pouvez déclarer ces domaines associés de manière centralisée à l'aide d'un dépôt crowdsourcé. Cela permet de s'assurer que les outils indépendants (tels que 1Password, qui ingère explicitement ce dépôt) reconnaissent également le contexte d'identité partagé. Pour en savoir plus sur l'association de sites d'applications Apple, consultez la section Compatibilité avec les domaines associés.

Pour activer les clés d'accès sur différents domaines Web et résoudre le problème lié aux clés d'accès roadblock, les développeurs peuvent héberger un fichier ROR (Related Origin Requests) sur /.well-known/webauthn. ROR déclare explicitement les domaines autorisés à partager de manière sécurisée le même ID RP de clé d'accès. Pour en savoir plus sur les requêtes d'origine associée, consultez la section Autoriser la réutilisation des clés d'accès sur vos sites avec les requêtes d'origine associée.

• Avantages :
  • Correction en arrière-plan pour les utilisateurs finaux : elle fonctionne entièrement en arrière-plan, ce qui résout automatiquement la fragmentation de la saisie automatique et établit la continuité des clés d'accès au niveau du système d'exploitation ou du navigateur sans aucune modification visible de l'expérience utilisateur.
  • Implémentation simple : il s'agit d'une solution peu coûteuse qui ne nécessite que l'hébergement de fichiers JSON statiques. Elle ne nécessite pas de réarchitecture backend ni de logique d'échange de jetons complexe.
  • Préserve l'infrastructure existante : vous pouvez améliorer considérablement le parcours interdomaine sans modifier votre marque ni consolider vos domaines.
• Inconvénients :
  • Contraintes de la plate-forme : les plates-formes appliquent généralement des limites strictes aux ROR. Par exemple, Chrome limite un seul ID RP à un maximum de cinq libellés eTLD+1 associés. Par exemple, example.co.uk et example.de partagent le même example libellé eTLD+1, tandis que example-rewards.com utilise un libellé example-rewards distinct. Si vous gérez un portefeuille de domaines étendu ou varié, ces limites peuvent être insuffisantes.
  • Latence opérationnelle accrue : la résolution des fichiers de métadonnées nécessite un aller-retour réseau supplémentaire, ce qui ajoute de la latence lorsque le navigateur traite l'authentification.

Utiliser des iFrame inter-origines

Si vous ne pouvez pas utiliser l'approche des fichiers de configuration de métadonnées en raison des limites de domaine ROR, les éléments iframe inter-origines offrent un chemin robuste et compatible avec les normes pour résoudre les problèmes de connexion interdomaine.

En intégrant une origine d'authentification centralisée (par exemple, auth.brand.example) en tant qu'iFrame dans une partie de confiance (par exemple, brand.example), vous pouvez interagir avec les champs de formulaire habituels et les API modernes. Pour les mots de passe, le gestionnaire d'identifiants du navigateur associe les actions de saisie automatique à l'origine de l'iFrame (auth.example). Cela permet aux utilisateurs d'accéder facilement à leurs identifiants centralisés sur différents sites.

Pour les clés d'accès, la fenêtre parente doit accorder l'accès à l'iFrame à l'aide du framework de la règle d'autorisation, ce qui permet à l'iFrame d'appeler WebAuthn pour s'authentifier par rapport à son propre ID RP d'origine. Dans les deux flux, CSP (Content Security Policy) est utile pour protéger les utilisateurs contre les attaques telles que le détournement de clic et les scripts intersites. Une fois l'authentification réussie, la session est établie avec un cookie partitionné et le jeton est transmis de manière sécurisée à la fenêtre parente à l'aide de postMessage().

• Avantages :
  • Identifiants centralisés : évite la fragmentation des identifiants. Une seule origine centralisée gère à la fois les mots de passe enregistrés et un ID RP de clé d'accès unifié, ce qui permet à des domaines distincts de partager ces identifiants sans avoir à consolider les domaines.
  • Authentification contextuelle : l'ensemble du flux de connexion, qu'il s'agisse de remplir automatiquement un mot de passe ou d'une validation avec une clé d'accès, se déroule de manière transparente dans le contexte de la page parente, ce qui évite les redirections fédérées perturbatrices.
  • Résilience aux protections de suivi : cette approche fonctionne correctement même avec des protections de suivi intersites strictes à l'aide de cookies partitionnés.
• Inconvénients :
  • Contraintes d'implémentation : cette architecture nécessite une ingénierie spécialisée. Elle nécessite un CSP strict (frame-ancestors) pour limiter l'intégration aux domaines parents approuvés et empêcher le détournement de clic, la configuration des règles d'autorisation HTTP pour activer l'API WebAuthn, ainsi qu'une messagerie inter-documents sécurisée et validée (postMessage()) pour atténuer les attaques par usurpation d'origine et CSRF. Découvrez les bonnes pratiques dans la section Clés d'accès dans les iFrame.

Suivre la fédération d'identité standard

L'adoption d'une fédération d'identité standard telle qu'OpenID Connect est une approche robuste et durable pour maintenir votre système de comptes. Cette approche formalise le workflow d'authentification en le consolidant en un seul domaine de fournisseur d'identité dédié, tel que auth.brand.example. Avec un protocole établi, les applications redirigent les utilisateurs vers ce hub central pour l'authentification avant de recevoir de manière sécurisée un transfert de jeton pour terminer la connexion sur le domaine cible. Bien qu'elle soit souvent associée à des connexions tierces (telles que Se connecter avec Google), la fédération standard est tout à fait valide et largement utilisée comme solution propriétaire pour remplacer les solutions de contournement fragiles.

• Avantages :
  • Langage d'ingénierie commun : les développeurs n'ont pas besoin d'apprendre ni de maintenir un protocole spécifique et personnalisé. Ils peuvent s'appuyer sur des connaissances établies du secteur et des bibliothèques complètes. Il existe également des solutions packagées.
  • Fiabilité éprouvée : les protocoles standards sont éprouvés, sécurisés et beaucoup moins fragiles que les implémentations ad hoc.
  • Facilement extensible : si l'organisation doit se fédérer avec un nouveau service tiers ou intégrer une acquisition ultérieurement, l'infrastructure d'identité est déjà équipée pour fournir des identifiants.
  • Expérience utilisateur cohérente : les utilisateurs reconnaissent la page IdP centralisée comme la source faisant autorité pour la marque, ce qui clarifie exactement quand et où les identifiants sont requis.
• Inconvénients :
  • Frais d'intégration élevés : le développement ou la migration vers un IdP centralisé entraîne des frais d'intégration élevés et nécessite une expertise en sécurité spécialisée. Les organisations doivent investir dans la refactorisation sécurisée de toutes les applications connectées pour prendre en charge les modèles sécurisés basés sur la redirection.
  • Redirections perturbatrices : le flux d'authentification nécessite de rediriger les utilisateurs du site d'origine vers une page de fournisseur d'identité centralisée, ce qui empêche une expérience de connexion fluide et contextuelle.

Consolider les sous-domaines

Une autre approche structurelle consiste à unifier tous les domaines en déplaçant les propriétés numériques disparates sous un domaine racine enregistrable commun (eTLD+1). Cela implique de transformer des domaines distincts tels que brand.example et service-app.example en sous-domaines tels que www.brand.example et service.brand.example.

• Avantages :
  • Gestion unifiée des identifiants : les gestionnaires de mots de passe peuvent reconnaître le domaine racine et traiter tous les sous-domaines comme une seule entrée, ce qui élimine les invites en double et la saisie manuelle des mots de passe.
  • Continuité des clés d'accès : les développeurs peuvent définir de manière native un ID RP de clé d'accès pour le domaine enregistrable, ce qui étend instantanément la prise en charge des clés d'accès à tous les sous-domaines associés. Dans ce cas, un ID RP de brand.example fonctionnera à la fois sur www.brand.example et service.brand.example.
  • Partage de session sans effort : la consolidation de la structure de domaine permet de partager une seule session à l'aide de cookies génériques (par exemple, en définissant un cookie sur Domain=brand.example).
• Inconvénients :
  • Contraintes de branding et de migration : cette approche peut imposer des limites de branding potentielles si votre organisation exige des domaines de premier niveau distincts. La migration est complexe et nécessite une gestion minutieuse des redirections HTTP et une correction étendue des configurations inter-origines héritées.

Conclusion

Pour assurer la continuité de l'identité, vous devez passer des intégrations de connexion ad hoc à des normes d'authentification établies. En évaluant les contraintes de l'entreprise par rapport à ces pratiques établies (telles que la fédération, la consolidation de domaine, les iFrame ou les métadonnées), vous pouvez éliminer les frictions de l'expérience utilisateur et améliorer l'authentification dans votre écosystème.

Pour en savoir plus sur des sujets connexes, n'oubliez pas de suivre notre blog et d'explorer d'autres ressources sur le portail d'identité de Chrome.