Résumé

  • Dans l'attaque décrite par RFC 10027, l'adversaire lance lui-même un parcours légitime puis remet à la victime le vrai code ou la vraie adresse de vérification. La victime s'authentifie sur le service officiel ; le jeton revient néanmoins à l'appareil adverse.
  • Ni la MFA, ni un code à usage unique, ni un jeton lié à une clé ne démontrent l'intention. Il faut conserver le lien entre initiateur, client, appareil consommateur, ressource, portée, action et conséquence, puis prouver la fin des sessions lors de la révocation.

Imaginons un technicien appelé pour « reconnecter » l'écran d'une salle. Son interlocuteur lui dicte un code. Sur son téléphone professionnel, le technicien ouvre l'adresse officielle, utilise sa passkey et voit le nom du service attendu. Il valide. L'écran de la salle ne reçoit rien : le code venait d'un client ouvert par l'interlocuteur sur son propre appareil.

Il n'y a eu ni fausse page, ni mot de passe volé, ni contournement de la cryptographie. L'erreur porte sur la relation entre deux contextes.

RFC 10027, BCP 247 publié en août 2026, distingue l'autorisation entre appareils du transfert de session et formalise deux familles d'attaque, l'une entre protocoles et l'autre au sein d'un même protocole. Dans les deux cas, un canal non authentifié relie l'appareil consommateur, qui demande l'accès, à l'appareil d'autorisation, où l'humain s'identifie.

Le code désigne une demande ; il n'en raconte pas l'origine

Le mécanisme de RFC 8628 répond à une contrainte réelle : un téléviseur ou un terminal sans clavier obtient un code d'appareil et un code utilisateur, affiche une route de vérification, puis interroge le serveur jusqu'à la décision prise sur un second appareil. Cette séparation rend le produit utilisable. Elle rend aussi le contexte transportable.

Un code court, unique et à usage unique réduit le temps d'attaque et empêche certaines réutilisations. Il ne certifie pas la provenance humaine du transfert. Un adversaire interactif peut attendre que son récit soit accepté, demander alors un nouveau code et utiliser la première validation. La cohérence mondiale des compteurs de rejeu peut en outre coûter en latence ou en disponibilité.

Le cadre OAuth 2.0 sépare client, propriétaire de ressource, serveur d'autorisation et serveur de ressources. PKCE rattache utilement l'échange du code d'autorisation au client qui détient le vérificateur. Mais si ce client est celui de l'attaquant, l'intégrité de l'échange protège précisément la mauvaise destination.

Une excellente authentification peut valider une mauvaise interprétation

WebAuthn niveau 3 permet une authentification résistante au hameçonnage et liée à l'origine. La passkey confirme que la personne a répondu au bon service. Elle ne confirme pas que la personne reconnaît l'appareil demandeur, le périmètre demandé ou l'effet commercial de l'autorisation.

Cela interdit un raccourci fréquent dans les tableaux de risque : « MFA réussie » ne peut pas compter comme preuve de confiance de l'appareil consommateur. RFC 10027 conseille d'éviter le flux de RFC 8628 pour les ressources sensibles, de grande valeur ou critiques pour l'activité, et de ne l'utiliser que lorsque les contraintes de l'appareil rendent les solutions plus fortes impraticables.

Les appareils préenregistrés et le principe « s'authentifier avant d'initier » empêchent un appareil arbitraire de créer la demande. La proximité peut perturber une attaque, mais le réseau mobile, le Wi-Fi, un VPN ou un relais rendent la distance ambiguë ; la collecte de localisation crée aussi un coût de vie privée. Un canal hors bande ou une vérification d'initiation n'a de valeur que si les faits présentés sont réellement liés à l'identifiant de demande et ne peuvent être simplement transmis à leur tour.

Après l'émission, le contrôle se disperse

DPoP lie un jeton à une clé détenue par le client. C'est une défense utile contre la copie. Si l'attaquant contrôle le client autorisé et sa clé, elle empêche surtout d'autres appareils d'utiliser le pouvoir que la victime lui a accordé par erreur. Les recommandations de RFC 9700 durcissent OAuth, sans pouvoir reconstruire l'intention absente.

OpenID CIBA supprime le transfert d'un code visible et réduit ainsi ce vecteur. Un demandeur connaissant l'identifiant de l'utilisateur peut toutefois provoquer une notification : rafales de demandes, fatigue d'approbation et faux support restent possibles.

Pour la réponse, l'introspection, la révocation et les événements CAEP apportent des signaux complémentaires. L'appel de révocation réussi prouve une réception par un serveur ; il ne prouve pas que tous les serveurs de ressources ont cessé d'accepter le jeton, ni que toutes les sessions dérivées sont mortes.

Un registre de contexte, pas un score unique

Chaque demande devrait conserver l'identifiant et l'heure d'initiation, le client et sa version, l'identité et l'état de confiance de l'appareil consommateur, l'appareil d'autorisation et la méthode d'authentification, l'empreinte et la durée du code, le canal de transfert, les signaux de proximité, ainsi que le texte exact montrant demandeur, ressource, portée, action, destinataire et conséquence irréversible.

Après décision, il faut rattacher la famille de jetons et la clé de confirmation aux usages observés par chaque serveur de ressources. Les refus, anomalies, introspections, révocations, événements CAEP, accusés de réception et preuves de fermeture demeurent des états distincts.

Le principe de primauté du code exécuté de Heng Lu rappelle que le serveur de ressources et l'appareil qui utilisent réellement le jeton ont le dernier mot opérationnel. Sa spécification initiale minimale avec décisions locales justifie un socle commun étroit pour la preuve de contexte, sans imposer un seul capteur de proximité. Enfin, sa distinction entre contrôle formel et contrôle pratique éclaire le paradoxe : le serveur d'autorisation signe le pouvoir formel ; l'appareil et les sessions qui l'exercent détiennent le pouvoir pratique.

Le téléphone a bien reconnu la personne. La gouvernance doit encore reconnaître la demande.