Principales conclusions
- Après avoir testé 38 applications supplémentaires depuis notre recherche initiale, Semperis en a trouvé deux qui étaient vulnérables à l'utilisation abusive de nOAuth. Nous avons signalé nos conclusions concernant ces deux applications aux éditeurs de logiciels.
- L'une des applications vulnérables disposait d'autorisations qui auraient permis à un pirate informatique de revenir dans Microsoft 365, ce qui confirme que nOAuth peut mettre en danger non seulement les données de l'application SaaS, mais aussi l'environnement Microsoft 365 d'une organisation.
- Dans notre dernier cas avec le Microsoft Security Response Center, le MSRC a évalué cette vulnérabilité comme modérée. Cependant, Semperis maintient son évaluation comme GRAVE. nOAuth reste difficile à détecter pour les clients des applications vulnérables et impossible à contrer pour eux. L'abus est documenté publiquement et présente une faible complexité une fois qu'une application vulnérable est identifiée.
Cet article fait suite à notre recherche initiale sur nOAuth. Même si cela semble être hier que nous avons publié ces résultats lors des conférences TROOPERS25 et fwd:cloudsec 2025, notre recherche a débuté à l'automne 2024.
Après avoir mené des recherches supplémentaires sur nOAuth six mois après notre discussion initiale, puis à nouveau un an après nos premières recherches, nous avons constaté que le risque d'abus de nOAuth existe toujours et que de nombreuses organisations ne sont toujours pas conscientes de cette vulnérabilité.
En octobre et novembre 2025, nous avons testé 38 applications supplémentaires pour détecter les abus nOAuth et en avons trouvé 2 qui étaient vulnérables. Au cours de nos recherches précédentes, nous avons testé 104 applications et en avons trouvé 9 vulnérables. Cela signifie qu'en pourcentage cumulé, environ 8 % des applications disponibles sont vulnérables à nOAuth.
Comprendre comment les applications SaaS s'intègrent à Microsoft 365
L'API Microsoft Graph est l'API unifiée permettant d'accéder à tous les services Microsoft 365 : Exchange Online, SharePoint, OneDrive et la plupart des autres services Microsoft 365. Les applications SaaS tierces qui souhaitent s'intégrer à ces services demandent l'accès à Microsoft Graph afin de pouvoir interagir avec les données ou les services des utilisateurs en leur nom.
Calendly en est un exemple : cette application demande l'autorisation d'accéder au calendrier d'un utilisateur afin de pouvoir gérer ses rendez-vous dans Office 365 (Figure 1). Pour plus de clarté, précisons que Calendly n'est pas vulnérable à nOAuth. Nous l'utilisons simplement comme application de référence pour vous aider à comprendre le comportement courant des applications SaaS.
Lorsqu'un utilisateur accède à l'application, tant que les autorisations ont été accordées, l'application SaaS reçoit un jeton d'accès OAuth 2.0 de la part d'Entra ID. L'application utilise ensuite ce jeton d'accès avec l'API Microsoft Graph pour accéder au service. Dans cet exemple, le jeton d'accès fourni à Calendly dispose des autorisations Calendar.ReadWrite et Calendar.ReadWrite.Shared.
Dans de nombreux cas, l'application SaaS reçoit également un jeton d'actualisation (Figure 2). Ce jeton permet à l'application SaaS de conserver l'accès aux données de l'utilisateur, même si celui-ci n'utilise pas activement l'application.
Pourquoi les applications SaaS ont-elles besoin de ce type d'accès ? Dans notre exemple, cet accès permet à Calendly de prendre des rendez-vous avec vos clients dans votre agenda, même si vous n'utilisez pas activement l'application. De cette façon, l'application SaaS peut continuer à « faire des choses » avec vos données en arrière-plan.
C'est excellent pour la productivité, et il n'y a rien de mal en soi dans les autorisations demandées. Mais lorsque ces autorisations sont associées à une vulnérabilité à nOAuth, les conditions sont réunies pour que des pirates puissent exploiter l'application et, potentiellement, revenir vers Microsoft 365.
La différence entre authentification et autorisation
Pour bien comprendre comment nOAuth peut faciliter le retour à Microsoft 365, vous devez savoir qu'OpenID Connect (OIDC) facilite l'authentification à l'aide d'un jeton d'identification, et qu'OAuth 2.0 facilite l'autorisation à l'aide d'un jeton d'accès. Lorsqu'un jeton d'actualisation accompagne un jeton d'accès, l'application SaaS peut obtenir de nouveaux jetons d'accès, que l'utilisateur soit authentifié ou non.
Au-delà des nuances linguistiques liées à l'identité, l'OIDC facilite la connexion d'un utilisateur à une application. OAuth 2.0 facilite les autorisations dont dispose une application pour accéder aux données d'un utilisateur. Un jeton d'actualisation permet à l'application d'accéder aux données de l'utilisateur, même si celui-ci n'est pas connecté (Figure 3).
Lorsqu'un utilisateur accède pour la première fois à une application, une authentification et une autorisation peuvent avoir lieu : l'application peut recevoir un jeton d'identification pour l'utilisateur et un jeton d'accès afin que l'application puisse accéder aux ressources Microsoft 365. Pour l'utilisateur final, ce processus est généralement transparent, sauf lorsque l'application n'a jamais été utilisée et qu'un consentement est nécessaire.
Il existe de nombreux frameworks et bibliothèques pour gérer les jetons, mais c'est finalement le développeur d'applications SaaS qui détermine comment les jetons sont gérés.
Lorsqu'un utilisateur s'authentifie par la suite, l'application peut (ou non) tenter de demander un nouveau jeton d'accès et de rafraîchissement, si les jetons existants sont toujours valides. L'authentification et l'autorisation étant essentiellement traitées comme des fonctions distinctes, cette déconnexion entre les deux flux permet aux attaquants de pivoter.
Abus de nOAuth pour passer à Microsoft 365
Au cours de nos recherches initiales, nous avons découvert une application vulnérable qui était intégrée à Microsoft 365 avec les autorisations Calendars.ReadWrite.Shared. Selon la documentation Microsoft, cette intégration :
Autorise l'application à créer, lire, mettre à jour et supprimer des événements dans tous les calendriers de l'organisation auxquels l'utilisateur est autorisé à accéder. Cela inclut les calendriers délégués et partagés.
Préoccupant, mais pas au point de permettre une attaque telle qu'une compromission des e-mails professionnels (BEC).
Cette fois-ci, nous avons trouvé un ensemble d'autorisations beaucoup plus large et préoccupant (figure 4) :
- Calendriers.LireÉcrire
- Envoyer un e-mail
- Contacts.LireÉcrire
- Mail.LireÉcrire
- accès hors ligne
Comme mentionné précédemment, ces autorisations sont préoccupantes, car elles permettent à un pirate non seulement de compromettre l'utilisateur au sein de l'application SaaS, mais aussi d'utiliser l'interface de l'application pour revenir vers Microsoft 365.
Rappelons que l'authentification et l'autorisation sont des fonctions distinctes qui utilisent des jetons différents. L'attaquant prend essentiellement le contrôle de l'accès des utilisateurs à Microsoft 365 via ces jetons d'accès et d'actualisation gérés dans l'application SaaS (Figure 5).
Dans l'application SaaS vulnérable, ce comportement se manifeste par la possibilité pour un pirate d'envoyer des e-mails en se faisant passer pour l'utilisateur compromis (figure 6).
Comme l'e-mail provient d'un utilisateur légitime du locataire, l'attaquant dispose désormais d'un moyen efficace pour se faire passer pour l'utilisateur compromis dans Exchange Online (Figure 7).
L'attaquant n'a pas directement accès au jeton d'accès, c'est donc l'interface utilisateur de l'application SaaS qui détermine comment il peut interagir avec les ressources Microsoft 365. Néanmoins, ces conclusions renforcent nos inquiétudes de longue date concernant nOAuth et les possibilités d'accès aux données et de chemins latéraux qu'il peut offrir.
Rechercher sur nOAuth revient à essayer de prouver une négative.
Lorsque nous avons publié nos conclusions en juin 2025, les questions les plus fréquentes que nous avons reçues concernaient le nombre total d'applications susceptibles d'être vulnérables. Cela est compréhensible, car les chiffres indéfinis ne font pas les gros titres.
Cependant, il était – et reste – impossible de quantifier le nombre d'applications susceptibles d'être vulnérables. Une recherche sur le nombre d'applications SaaS existantes donne un résultat compris entre 70 000 et plus de 300 000. Le catalogue d'applications Microsoft 365 Defenders Cloud répertorie 36 932 applications SaaS, mais toutes ne s'intègrent pas à Entra ID pour l'authentification.
Peu importe comment vous calculez les chiffres, cela restera une estimation. Dans le cas le plus bas, si 50 % de toutes les applications utilisent Entra ID pour l'authentification, alors tester 142 applications (sur 35 000) nous donne un taux de test de 0,4 %. Dans le cas le plus élevé (150 000 applications), cela nous donnerait un taux de test de 0,098 %.
Chez Troopers, j'ai déclaré que nous avions trouvé neuf applications vulnérables, et je doute que nous ayons trouvé 90 % de toutes les applications vulnérables. Aujourd'hui, avec nos nouvelles découvertes, je doute que 11 soit le nombre total d'applications vulnérables existantes. C'est tout simplement impossible à savoir.
Microsoft saurait combien d'applications sont configurées avec removeUnverifiedEmailClaim défini sur false et combien d'applications bénéficient d'une clause d'antériorité pour utiliser cette revendication. Mais cela n'indique pas si l'application est vulnérable.
En ce qui concerne les autorisations, bien que nous n'ayons constaté des abus que dans les applications intégrées à Exchange Online, les intégrations à SharePoint et OneDrive sont tout aussi courantes. Il serait naïf de croire que seul un certain pourcentage des applications intégrées à ces services sont vulnérables à nOAuth. Il existe des centaines d'autres autorisations Microsoft Graph, dont beaucoup seraient très préoccupantes si un pirate informatique venait à s'en emparer. En fait, c'est l'objectif principal d'une autre attaque très courante : les autorisations illicites.
Chronologie et réponse du MSRC
- 18 novembre 2025 : grâce à ces nouvelles découvertes spécifiques à Microsoft 365 et à cette possibilité de revenir en arrière, nous avons ouvert un dossier auprès du MSRC. Nous avons fourni tous les détails de nos découvertes, par écrit et dans une vidéo montrant l'attaque contre notre utilisateur test. Nous avons également demandé au MSRC de supprimer la possibilité d'envoyer une demande par e-mail non vérifiée. Comme nous l'expliquons dans notre article initial, il existe d'autres moyens de recevoir la demande par e-mail.
- 3 décembre 2025 : le MSRC a répondu que le cas était considéré comme présentant un risque modéré et a clos le dossier. Dans sa réponse, le MSRC a déclaré ce qui suit :
Après une enquête minutieuse, nous avons évalué ce cas comme présentant une vulnérabilité de gravité modérée. Nos équipes produits/services respectives ont été informées de ce problème et pourraient travailler à l'ajout de mécanismes de défense en profondeur supplémentaires, si nécessaire, dans les prochaines versions.
En conséquence, nous classons cette affaire.
Pourquoi nOAuth reste important
Nous continuerons à rechercher les applications vulnérables à nOAuth et à plaider en faveur d'un changement chez Microsoft, pour plusieurs raisons :
- Les abus liés à nOAuth sont documentés publiquement.
- Des recherches ont démontré l'accès à des informations sensibles sur des plateformes telles que les systèmes de gestion des ressources humaines (SGRH).
- Des recherches ont démontré qu'il existe des voies potentielles de mouvement latéral pour revenir à Microsoft 365.
- Les clients des applications vulnérables n'ont aucun moyen de se défendre contre nOAuth.
- Les chercheurs en sécurité ont démontré qu'il était relativement facile d'identifier les clients des applications SaaS.
- Il est également facile d'utiliser des plateformes telles que LinkedIn pour cibler les utilisateurs privilégiés d'applications SaaS et déduire leurs adresses e-mail.
Aperçu de Semperis
Bien que les entreprises ne disposent pas de défenses solides contre nOAuth, il est important de comprendre le risque lié à vos données. Avant d'adopter une nouvelle application SaaS, demandez au fournisseur s'il est au courant des recherches sur nOAuth et renvoyez-le vers nos blogs.
Pour les fournisseurs et les développeurs, il est essentiel de respecter les spécifications OpenID Connect de Microsoft afin de garantir que votre application n'est pas vulnérable à nOAuth. Pour plus d'informations, consultez nos recherches précédentes.
Ressources connexes
• Alerte d'abus nOAuth : prise de contrôle totale des applications SaaS multi-locataires Entra
• Session à la demande nOAuth (TROOPERS25)
