Le flux OAuth par code d’appareil répond à un vrai besoin. Un téléviseur, une console ou une imprimante affiche un code, puis la personne termine la connexion sur un navigateur plus confortable. Le problème apparaît lorsque le code vient d’un appareil qui appartient à quelqu’un d’autre.
- Prétexteinvitation, document ou faux support
- Codegénéré pour l’appareil attaquant
- Page légitimela cible se connecte au vrai service
- Jetonsaccordés au client de l’attaquant
Le domaine peut être parfaitement légitime
Dans ce scénario, l’attaquant lance lui-même un flux d’autorisation et transmet le code à sa cible. La personne ouvre ensuite le vrai site du fournisseur, saisit le code et utilise son facteur habituel. Le protocole fonctionne. Le service reconnaît correctement l’utilisateur.
Ce que cette authentification ne dit pas, c’est à qui appartient l’appareil qui a demandé l’accès. Le bénéficiaire est le client lancé par l’attaquant. Le conseil « vérifiez le cadenas » ne répond donc qu’à une partie de la situation.
La RFC 8628, qui définit ce flux, mentionne déjà le risque de sollicitation à distance. Le code relie le navigateur à une demande, pas nécessairement à l’intention que la personne lui attribue.
Une invitation à une réunion peut suffire
Microsoft a décrit en février 2025 une campagne attribuée à Storm-2372. Les prises de contact passaient par des messageries, puis par de fausses invitations à des réunions. Le code d’appareil était présenté comme une étape normale pour rejoindre l’échange. Une fois l’autorisation terminée, les attaquants récupéraient des jetons donnant accès aux informations du compte, notamment aux courriels.
L’attribution géopolitique publiée par Microsoft ne change pas le mécanisme technique. Ce qui m’intéresse ici, c’est l’enchaînement : une raison crédible de se connecter, une page officielle et une autorisation accordée au mauvais client.
Le passage à l’échelle en 2026
Une analyse Microsoft d’avril 2026 décrit une campagne plus automatisée. Les messages étaient adaptés aux fonctions professionnelles et les codes générés au moment où la personne interagissait avec le leurre. Cette génération dynamique évitait que le délai de quinze minutes s’écoule avant l’arrivée de la cible.
L’expiration n’a pas été cassée. L’attaquant a simplement déplacé le début du compteur au bon moment. L’automatisation gérait ensuite le suivi de l’autorisation et la validation des jetons obtenus. Selon Microsoft, certaines activités postérieures visaient les règles de boîte mail, la reconnaissance via Microsoft Graph et la recherche de profils disposant de responsabilités financières.
Trois questions différentes dans le même écran
Ce parcours rapproche trois décisions :
- la personne a-t-elle prouvé son identité ?
- veut-elle réellement accorder un accès ?
- reconnaît-elle l’application ou l’appareil qui recevra cet accès ?
Un bon facteur d’authentification traite surtout la première question. L’interface et la politique d’autorisation doivent encore rendre les deux autres compréhensibles. C’est aussi pourquoi une passkey ou une clé FIDO ne règle pas, à elle seule, tous les abus OAuth.
Réduire le parcours disponible
Lorsque l’autorisation par code d’appareil n’est pas utilisée, la bloquer supprime directement cette voie. Lorsqu’elle est nécessaire, l’organisation peut limiter les populations, les clients et les ressources autorisés, puis surveiller les demandes inhabituelles et les jetons émis.
La sensibilisation peut être très simple : ne saisir un code d’appareil que pour une connexion que l’on vient soi-même de lancer sur un équipement connu. Cette règle devient vraiment utile si l’interface nomme clairement l’application bénéficiaire et si les équipes disposent d’un moyen rapide de révoquer les jetons après une erreur.