Le jeton qui contourne la MFA : pourquoi le vol d’OAuth devient la nouvelle brèche d’entrée

7 min de lecture

L’authentification multifacteur verrouille la connexion. Cependant, elle ne protège pas la clé délivrée après la connexion. C’est précisément là que les attaquants interviennent désormais : ils dérobent des jetons OAuth qui contiennent déjà une MFA validée et accèdent ainsi aux services SaaS sans jamais déclencher de demande de second facteur. Le phishing OAuth a été multiplié par près de trente-neuf au cours de l’année écoulée. Plus de mille environnements SaaS ont été touchés.

Sur le même sujet :Le périphérique Edge comme porte d’entrée des ransomwares  /  Quand le produit de protection est lui-même la faille

Comment un jeton contourne la MFA

Qu’est-ce qu’un jeton OAuth ? Un jeton OAuth est un justificatif d’autorisation numérique qu’un service délivre après une connexion réussie. Au lieu de se reconnecter avec un mot de passe et un second facteur à chaque requête, l’application présente ce jeton. Il confirme : cet accès a déjà été authentifié. C’est précisément cette commodité qui constitue la vulnérabilité.

La logique est d’une simplicité déconcertante. La MFA agit au moment de la connexion. Ensuite, le service délivre un jeton de session ou OAuth qui représente l’état authentifié. Quiconque met la main sur ce jeton n’a plus besoin de se connecter. Il présente la clé que la MFA a déjà approuvée. Le second facteur n’est pas piraté, il est contourné, car au moment de l’attaque, il appartient déjà au passé.

L’abus de la procédure de code d’appareil (Device Code) est particulièrement perfide. Elle permet normalement la connexion d’appareils sans clavier, comme les Smart TV. Les attaquants incitent leur victime à confirmer un code qui, en réalité, donne accès à l’appareil de l’attaquant. La victime effectue une véritable MFA légitime et approuve ainsi, sans le savoir, la session étrangère. Du point de vue du service, tout est correct, un utilisateur autorisé a donné son accord.

Pourquoi la MFA classique est ici inefficace

Le constat est sans appel : la MFA a été conçue pour résoudre un problème différent. Elle empêche qu’un mot de passe volé ne suffise à lui seul. Mais face à un jeton (token) dérobé après une connexion réussie, elle est inutile, car elle n’intervient plus à ce stade. Considérer la MFA comme une mesure ultime revient à verrouiller la porte tout en oubliant que l’attaquant passe par la fenêtre ouverte de la session.

Cela déplace la défense de la connexion vers la session elle-même. Il ne suffit plus de vérifier l’accès une seule fois. La session doit être surveillée et limitée. Un jeton valide indéfiniment et accepté depuis n’importe quel endroit est une clé permanente. Un jeton qui expire rapidement, lié à un appareil et à une localisation, et révoqué en cas d’anomalie, perd considérablement de sa valeur en cas de vol.

Ce qu’un SOC devrait concrètement faire

Le premier levier est la durée de vie du jeton. De nombreux services SaaS autorisent des valeurs par défaut généreuses pour éviter de forcer les utilisateurs à se reconnecter trop souvent. C’est précisément ce confort qu’il faut auditer. Une validité réduite et une ré-authentification forcée lors d’actions sensibles réduisent la fenêtre temporelle durant laquelle un jeton volé est exploitable.

Le second levier est l’accès conditionnel (Conditional Access). Un jeton ne devrait pas être valide partout. Si une même session est soudainement utilisée depuis un autre pays ou un appareil inconnu, elle doit être remise en question et non acceptée tacitement. Ce contrôle contextuel est la véritable réponse au vol de jeton, car il ne sécurise pas la connexion, mais l’utilisation.

La MFA verrouille la porte. Si l’attaquant copie la clé émise après coup, la meilleure des serrures ne sert à rien. C’est la session qu’il faut défendre, pas seulement le login.

Le troisième levier concerne la procédure de code d’appareil (Device Code) elle-même. Là où elle n’est pas nécessaire, elle doit être restreinte ou désactivée. De plus, les collaborateurs doivent savoir qu’une demande de confirmation de code mérite la même méfiance qu’une demande de mot de passe sur un site inconnu. Un code confirmé peut autoriser une session tierce. Cette simple information permet de prévenir une grande partie des attaques par code d’appareil.

Aucun de ces trois leviers ne remplace la MFA. Elle reste la base. Mais elle constitue la première ligne de défense, et non la dernière. Quiconque perd de vue la session après la connexion a abandonné la défense là où les attaques actuelles se concentrent. La bonne nouvelle : la durée de vie des jetons, l’accès conditionnel et l’hygiène des codes d’appareil sont configurables, nul besoin de les inventer.

Foire aux questions

La MFA est-elle contournée lors d’un vol de jeton OAuth ?

Non, elle est contournée. Le jeton est généré après une MFA réussie et porte en lui l’état authentifié. Celui qui le vole n’a plus besoin de se connecter et ne déclenche donc aucune nouvelle demande de facteur.

Qu’est-ce que l’abus de code d’appareil (Device Code) ?

La procédure de code d’appareil permet la connexion d’appareils sans clavier. Les attaquants incitent une victime à confirmer un code qui, en réalité, donne accès à l’appareil de l’attaquant. La victime effectue une véritable MFA et autorise, sans le savoir, la session étrangère.

Pourquoi la MFA ne suffit-elle pas face à ces attaques ?

La MFA intervient au moment de la connexion. L’attaque se produit après, lors de la session déjà établie. À ce stade, la MFA n’est plus impliquée, c’est pourquoi elle ne peut pas bloquer le jeton volé.

Quelle mesure est la plus rapide à mettre en œuvre ?

Vérifier et réduire la durée de vie des jetons, ainsi qu’activer le Conditional Access. Ces deux actions réduisent la fenêtre temporelle et le champ d’application d’un jeton volé, sans pour autant remplacer la MFA.

Faut-il désactiver la procédure de code d’appareil (Device Code) ?

Là où elle n’est pas nécessaire, oui. Là où elle est indispensable, elle doit être restreinte et surveillée. De plus, sensibiliser le personnel au fait qu’un code à confirmer peut autoriser une session tierce est une aide précieuse.

Source de l’image : générée par IA (mai 2026)

À propos de l'auteur: Benedikt Langer

Plus d'articles de Benedikt Langer