Se connecter avec Google, Apple ou Microsoft

« Continuer avec Google. » Un bouton, deux secondes, et te voilà inscrit sur l'outil de facturation que tu viens de découvrir. Tu n'as pas choisi de mot de passe. Tu n'as rien à retenir. Tu viens surtout de décider que ce compte vaudra exactement ce que vaut ton compte Google, et rien au-delà.

On se demande d'habitude si ce bouton est plus sûr qu'un mot de passe. La question ne se pose pas dans cet axe. La fédération est le seul mécanisme d'authentification qui déplace la serrure au lieu d'en poser une, donc la vraie question est : qu'est-ce qui garde le compte vers lequel elle la déplace ? Voici d'où elle vient, ce qu'elle retire comme chemin d'entrée, et pourquoi le simulateur marque un défaut de structure dès qu'un compte s'ouvre par un compte tiers moins protégé que lui.

D'où ça vient

OAuth 2.0 a été publié le 1er octobre 2012 par l'IETF, sous le numéro RFC 6749. La spécification décrit un cadre qui permet à une application tierce d'obtenir un accès limité à un service HTTP pour le compte de son propriétaire. C'est de l'autorisation déléguée : « laisse cette application lire mon agenda ». Prouver une identité n'était pas son objet.

La couche d'identité est arrivée le 26 février 2014, avec la version finale d'OpenID Connect Core 1.0. Elle pose par-dessus OAuth un jeton d'identité signé, que le service peut vérifier : qui a authentifié la personne, quand, et avec quelle méthode. C'est ce jeton qui fait fonctionner le bouton « Continuer avec » tel que tu le connais aujourd'hui.

Apple est arrivé le 3 juin 2019, à sa conférence développeurs, avec « Se connecter avec Apple ». La nouveauté n'était pas le protocole mais l'option « Masquer mon adresse e-mail » : le service reçoit une adresse relais générée pour lui seul, différente pour chaque application, et Apple fait suivre les messages vers ta vraie boîte. Tu peux couper cette adresse sans toucher aux autres.

Le problème que ça résout

Il n'y a plus de mot de passe sur le service. Donc plus rien à rejouer depuis une fuite : le rejeu d'identifiants fuités, que le simulateur compte à 0,90 pour l'opportuniste sur un mot de passe réutilisé, n'a aucune prise. Plus rien à casser hors ligne non plus, puisque le service ne stocke aucune empreinte. Le jour où sa base fuite, elle ne livre pas de secret réutilisable ailleurs.

Le second gain porte sur l'attention. Protéger sérieusement un compte coûte du temps et de l'argent : le simulateur chiffre un gestionnaire de mots de passe à 3, une paire de clés physiques à 10. Ce coût ne se répète pas trente fois si trente services s'ouvrent par le même compte tiers. Tu concentres l'effort sur une serrure, celle qui compte.

Quand ce compte tiers est protégé par un code temporaire (TOTP), le simulateur compte la technique « compte tiers » à 0 pour l'opportuniste, 0,02 pour le ciblé, 0,10 pour le proche. Ce sont les meilleurs chiffres du tableau pour un chemin d'entrée qui ne repose pas sur une clé physique.

Les problèmes que ça ajoute

Ces deux gains sont réels, et pour la plupart des comptes ils suffisent à justifier le bouton. Le coût arrive après, et il se lit en quatre points.

Le compte tiers devient la vraie serrure. Le moteur du simulateur signale ce cas comme un défaut de structure : un compte ne vaut jamais plus que celui qui sert à y entrer. Poser un mot de passe long et un second facteur sur le service fédéré ne rattrape rien, parce que l'attaquant n'a pas à les franchir. Il passe par la porte qu'on a ouverte. Ajouter une porte n'améliore jamais la note.

La suspension sans interlocuteur. Un compte de plateforme peut être fermé par une décision automatique. Le New York Times a documenté en août 2022 le cas d'un père dont le compte Google a été désactivé après qu'un filtre a classé comme contenu illicite des photos médicales de son fils, envoyées à un médecin ; son recours a été rejeté, et il a perdu près de dix ans de courriers, de contacts et de photos, en même temps que sa ligne téléphonique. Tout ce qui s'adossait à ce compte s'est éteint le même jour. Le simulateur en fait un des six scénarios de Récupérabilité, avec un poids de 1.

Les autorisations survivent au changement de mot de passe. Changer le mot de passe du compte tiers ne retire pas les accès déjà accordés aux applications. Ces autorisations vivent dans une page séparée du compte, à ouvrir explicitement. Une application autorisée il y a trois ans garde son jeton, et le mot de passe tout neuf n'y change rien.

La page relais traverse la fédération. Une page relais en temps réel franchit l'identifiant, le mot de passe, le SMS, le code temporaire, le code par email, la notification, et le compte tiers. Elle ne franchit pas la clé d'accès (passkey), qui refuse de signer pour un domaine qui n'est pas le bon. Autrement dit, si le compte tiers est protégé par autre chose qu'une clé d'accès, une seule page relais suffit à traverser toute la chaîne jusqu'au service fédéré.

Un dernier point, souvent invisible : chez Google et Microsoft, le compte tiers est aussi la boîte email. Une seule prise de contrôle donne alors la fédération et la réinitialisation de tout le reste. L'email comme facteur détaille cette seconde moitié.

Les niveaux

Le simulateur ne distingue pas les fournisseurs. Il distingue ce qui protège le compte tiers.

L'écart entre la première et la troisième ligne est le seul qui compte vraiment pour toi : passer d'un mot de passe seul à un code temporaire divise par plus de vingt les chances de l'attaquant ciblé.

Pourquoi la quatrième ligne se lit-elle moins bien que la troisième, alors que la clé d'accès est le meilleur facteur contre l'hameçonnage ? Parce que la ligne ne note pas la clé, elle note le compte de plateforme qui la synchronise. Dans ce modèle, « clé d'accès » suppose un trousseau synchronisé, donc un compte qui garde ses propres chemins de récupération ouverts. Le chiffre punit ces chemins-là. C'est une règle écrite, et elle se discute : une clé d'accès posée sur un compte dont la récupération assistée est fermée bat le code temporaire dans les trois colonnes.

Les scénarios d'attaque

L'opportuniste automatisé est mal servi par la fédération, et c'est son intérêt principal. Sans mot de passe à rejouer, ses listes ne valent plus rien sur ce compte. Sa seule vraie prise reste la boîte email, s'il peut la reprendre.

L'attaquant ciblé garde la page relais, à 0,33 avant réductions. C'est le chiffre qui justifie la clé d'accès sur le compte tiers plutôt qu'un code temporaire : la clé est le seul facteur du tableau que cette technique ne franchit pas.

Le proche joue une autre partition. Il n'a pas besoin d'ouvrir une session : il en trouve une déjà ouverte sur un appareil déverrouillé, et la fédération lui donne alors accès à tous les services d'un coup, sans rien retaper.

Ce qu'il faut faire

Le plafond ne vient pas du bouton. Il vient du compte qu'on a choisi de mettre derrière, et c'est là que le geste se joue.

1. Pose une clé d'accès sur le compte tiers. Effort 1 selon le barème, pour l'objet qui plafonne tous les autres. Si le fournisseur ne le propose pas encore, un code temporaire en application fait déjà l'écart le plus grand.

2. Ferme la récupération du compte tiers. Une clé d'accès posée devant une récupération par SMS ou par questions secrètes ne sert qu'à moitié. Les portes de service traite ce point en entier.

3. Garde un accès direct sur les services qui comptent. Quand un service accepte à la fois la fédération et un mot de passe, pose les deux, avec un second facteur. La suspension du fournisseur cesse alors d'être une porte fermée définitivement. Ce conseil va contre la règle générale, qui veut qu'on ferme les portes : il achète de la Récupérabilité au prix d'un peu de Résistance, et c'est un arbitrage à faire en connaissance de cause.

4. Ne fédère pas les comptes de dernier recours. Banque, registrar de domaine, hébergeur, coffre à secrets : ces comptes-là ne devraient pas dépendre du fournisseur qui héberge aussi ta boîte email.

5. Ouvre la page des applications autorisées, une fois par an. Retire ce qui ne sert plus. Un accès accordé reste accordé jusqu'à ce que tu le retires.

Ce qui dépend du service et pas de toi : proposer plusieurs fournisseurs, accepter aussi une inscription directe, et avertir par un canal séparé quand un accès est accordé.

Ce que ce modèle ne dit pas

Le simulateur mesure l'authentification, et son périmètre s'arrête là, par construction. Il ne dit rien de ce que le fournisseur d'identité apprend de toi au passage, ni du fait qu'il voit chaque connexion à chaque service. Il ne couvre pas non plus la compromission complète du poste ni le vol d'une session déjà ouverte, deux situations où la question du facteur ne se pose plus. Pour celles-là, le geste utile se trouve dans le journal des sessions du compte tiers, et dans le bouton qui déconnecte partout.

Pour la suite : Les clés d'accès (passkeys) explique le facteur à poser sur le compte tiers, et Un compte vaut son chemin le plus faible présente le modèle complet.