Lien bidirectionnel vérifié sur une plateforme d’identité à neuf marques

Cette flexibilité a créé un problème d’identité. Lorsqu’un client se connectait avec une nouvelle identité Apple ou Google dont l’adresse e-mail appartenait déjà à un compte existant, la plateforme devait décider quoi faire. Lier les deux automatiquement sur une seule correspondance par email serait dangereux : une adresse email correspondante suggère une relation, mais cela ne prouve pas que la personne qui se connecte contrôle réellement cette boîte de réception. La plateforme avait besoin d’un moyen de connecter les identités compatibles Apple et Google à un seul compte partagé sans jamais accorder un accès à une correspondance par e-mail seul, et de le faire de manière cohérente sur les neuf marques, y compris les cas délicats : adresses relais privées d’Apple, comptes avec mot de passe, connexions risquées et pannes des fournisseurs.

Les contraintes étaient concrètes. Le lien devait être bidirectionnel et indépendant de l’ordre : Google d’abord puis Apple, ou Apple d’abord puis Google, devait atteindre le même compte partagé. Le « Cacher mon e-mail » d’Apple devait être géré séparément, car une adresse relais privée qui ne correspondait pas à l’adresse e-mail réelle du client ne devait pas se lier silencieusement à ce compte. La vérification a dû réutiliser le même mécanisme de défi de code déjà fiable pour l’authentification à risque élevé, ce qui a permis d’hériter des contrôles éprouvés plutôt que d’en inventer de nouveaux. Le risque devait moduler la friction : les inscriptions à faible risque devaient rester sans friction tandis que les risques moyen, élevé et indéterminé nécessitaient un OTP. Les échecs répétés devaient être contenus par une politique de blocage applicable au niveau du compte, sur toutes les marques, et non par marque. Et les défaillances des fournisseurs devaient être sûres, sans jamais laisser un client avec un compte partiel ou en double.

Le même chemin vérifié couvrait les deux directions de liaison. Si un client créait un compte chez Google puis choisissait Continuer avec Apple en utilisant la même adresse e-mail partagée, le système détectait le compte existant, envoyait un code à son e-mail et liait Apple après vérification réussie. L’inverse, Share My Email d’Apple d’abord et Google ensuite, a résolu le même compte partagé grâce au même défi. Après la liaison, le client pouvait se connecter avec Apple, Google, ou par email et mot de passe, là où l’un avait été configuré, et se retrouver sur le même compte.

Le programme « Cacher mon courriel » d’Apple est resté délibérément séparé. Lorsque l’adresse de relais privé ne correspondait pas à l’adresse e-mail personnelle non divulguée du client, les identités n’étaient pas éligibles pour le lien avec le même e-mail. Plutôt que de lier le relais à un compte non lié, la plateforme a montré une explication à accès limité et a créé un compte relais de messagerie séparé. Au-delà du premier lien, le même compte avait son propre cycle de vie : un client pouvait définir un mot de passe sur un compte social, modifier l’adresse principale (ce qui a délié l’ancien fournisseur social et nécessitait une revérification), et chaque connexion retournée passait toujours par une évaluation des risques avant l’émission d’une session.

À partir de là, le flux s’est divisé vers des résultats clairement limités. Une correspondance par email éligible émettait un code de lien vers l’adresse e-mail du compte existant ; Après vérification réussie, le fournisseur était lié ; en cas d’échec, la tentative était rejetée et enregistrée. Un e-mail relais Apple qui ne correspondait pas a été acheminé vers une explication à accès limité et un compte relais séparé. Une fois le statut du compte partagé entre marques était résolu : un compte bloqué était affiché comme bloqué, un compte actif était classé dans une catégorie de risque. À faible risque, une session authentifiée est envoyée directement ; un risque moyen, élevé et indéterminé a envoyé un OTP d’authentification, et des défis répétés échoués, jusqu’à un seuil fixe, ont bloqué le compte partagé sur les neuf marques. Le compte lui-même exposait la configuration du mot de passe et les changements d’email, où changer l’adresse principale déconnectait l’ancien fournisseur social et nécessitait une nouvelle vérification du fournisseur. Les défaillances du service fournisseur ne créaient pas d’état partiel : elles renvoyaient une erreur de sécurité et une nouvelle tentative qui renvoyait dans le même orchestrateur, de sorte qu’un appel Apple ou Google raté ne produisait jamais de compte à moitié lié ou dupliqué. La frontière de liaison combinait trois vérifications : une réponse validée par le fournisseur, une correspondance compatible avec le même email, et un défi de code email réussi, et les soumissions de code ratées suivaient la même politique de contrôle de défi et de blocage que les OTP de risque.