En février 2026, la plateforme **EvilTokens** a été lancée, démontrant rapidement les dangers du consentement OAuth non contrôlé. Les cibles ont été trompées pour entrer un code sur `microsoft.com/devicelogin` et compléter un défi MFA, accordant sans le savoir aux attaquants un jeton de rafraîchissement avec de larges permissions, y compris l'accès aux boîtes aux lettres, aux lecteurs, aux calendriers et aux contacts. Ce jeton persistait selon la politique du locataire, dépassant largement la durée de vie d'une session typique. Cette attaque contourne les mesures de sécurité traditionnelles car elle n'implique pas de mots de passe volés ni d'événements de connexion suspects. Au lieu de cela, elle exploite la normalisation des écrans de consentement OAuth, où les utilisateurs cliquent souvent instinctivement sur 'Accepter' sans comprendre pleinement les permissions accordées. ## Pourquoi la MFA échoue contre l'abus de consentement OAuth Le phishing d'identifiants traditionnel repose sur la relecture de noms d'utilisateur et de mots de passe volés, déclenchant des invites MFA et laissant une trace que les systèmes de gestion des informations et des événements de sécurité (SIEM) peuvent détecter. Cependant, l'abus de consentement OAuth ne produit pas de telle relecture. L'utilisateur s'authentifie auprès du fournisseur d'identité légitime, complète la MFA et accorde le consentement. Le jeton résultant est valide, signé par le fournisseur d'identité et peut être rafraîchi, rendant la MFA inefficace pour bloquer l'attaque. <table><tbody><tr><td></td></tr><tr><td>Figure 1 : Le phishing d'identifiants laisse une trace de connexion que le SIEM peut corréler.</td></tr></tbody></table> <table><tbody><tr><td></td></tr><tr><td>Figure 2 : Un consentement OAuth ne laisse pas de relecture, juste un jeton actualisable.</td></tr></tbody></table> De plus, les jetons de rafraîchissement émis par **EvilTokens** restaient valides même après des réinitialisations de mot de passe, persistant pendant des semaines ou des mois en fonction de la configuration du locataire. Seule une révocation explicite ou des politiques d'accès conditionnel nécessitant un nouveau consentement pouvaient mettre fin à l'octroi. ## La normalisation du consentement Le vecteur d'attaque par consentement OAuth n'est pas nouveau, mais son efficacité a augmenté en raison de la désensibilisation des utilisateurs. Les utilisateurs sont bombardés d'écrans de consentement par des agents IA, des intégrations de productivité et des extensions de navigateur, ce qui conduit à une mentalité de 'clic-à-travers' similaire aux bannières de cookies. Le langage utilisé dans les étendues de consentement masque souvent l'étendue réelle des permissions accordées. Par exemple, 'Lire votre courrier' peut englober chaque message, pièce jointe et fil de discussion partagé. Cet écart entre le langage du consentement et la portée opérationnelle est exploité par les attaquants. ## Combinaisons toxiques : Risque inter-applications Le véritable danger réside dans la combinaison de plusieurs consentements OAuth à travers différentes applications, créant ce que les chercheurs appellent des 'combinaisons toxiques'. Par exemple, un utilisateur financier accordant l'accès à son calendrier et à sa boîte aux lettres à un résumeur de réunions IA, puis accordant l'accès au lecteur partagé de l'entreprise à un assistant de productivité, crée une surface de risque où une compromission dans une application peut se propager à d'autres. <table><tbody><tr><td></td></tr><tr><td>Figure 3 : Une combinaison toxique entre deux applications SaaS que le propriétaire n'a pas sanctionnées ensemble.</td></tr></tbody></table> L'incident **Salesloft**-**Drift** en 2025 a mis en évidence ce risque à grande échelle. Un connecteur en aval compromis s'est propagé à plus de 700 locataires **Salesforce** via des jetons OAuth légitimes, démontrant l'effet de cascade des intégrations compromises. ## Mesures proactives pour atténuer les risques OAuth Les organisations doivent traiter le consentement OAuth avec la même rigueur que l'authentification. Les principaux domaines à examiner comprennent : * **Inventaire des applications OAuth :** Surveiller en permanence toutes les applications tierces détenant des jetons de rafraîchissement. * **Âge des octrois et nouveau consentement :** Signaler les jetons émis il y a longtemps sans nouveau consentement. * **Identités inter-applications :** Identifier les identités détenant des octrois sur plusieurs applications SaaS. * **Ponts d'agents et d'intégrations :** Détecter les agents IA et les intégrations reliant les systèmes sans autorisation explicite. * **Accès conditionnel au consentement :** Mettre en œuvre des politiques déclenchées par des événements de consentement, et pas seulement par des événements de connexion. * **Révocation au niveau du jeton :** Établir des plans d'action pour révoquer les jetons OAuth individuels. Ces mesures nécessitent une plateforme capable de surveiller en continu la couche d'exécution où ces ponts se forment, car la discipline procédurale seule ne peut pas s'adapter à la vitesse à laquelle ces risques émergent. ## Plateformes de sécurité IA Une nouvelle catégorie de plateformes émerge pour automatiser une grande partie de ce processus, en cartographiant les octrois OAuth, les agents IA et les intégrations tierces pour fournir une visibilité et un contrôle complets sur le paysage OAuth.