Comprendre l’erreur AADSTS70000 « invalid grant » dans Microsoft Azure et M365

By Mirko Peters · 2026-04-21

L’erreur AADSTS70000 « invalid grant » est un casse-tête courant pour les administrateurs et les développeurs qui travaillent avec Azure Active Directory et les services Microsoft 365. Vous…

Automatically translated with AI from the original post. Read the English original

L’erreur AADSTS70000 « invalid grant » est un casse-tête courant pour les administrateurs et les développeurs qui travaillent avec Azure Active Directory et les services Microsoft 365. Vous la rencontrez souvent lors de la connexion de systèmes ou d’automatisations via Power Platform, des complémentaires Outlook ou des applications qui reposent sur les flux d’authentification Microsoft.

En bref, l’erreur AADSTS70000 signale un problème d’authentification survenu lorsqu’une application ou un utilisateur tente d’obtenir un jeton via OAuth, alors que l’octroi d’accès n’est plus valide. Elle peut interrompre un flux Power Automate, casser une intégration Outlook ou perturber la connexion à toute application qui utilise Azure ou Entra ID pour l’authentification. Si vous travaillez dans l’informatique cloud ou le développement d’applications, prenez cette erreur au sérieux : elle révèle des problèmes d’authentification et de sécurité capables de paralyser vos systèmes.

Savoir comment et où cette erreur peut se manifester est essentiel pour un dépannage rapide et permet d’éviter ces moments exaspérants où un service cesse de fonctionner du jour au lendemain, sans le moindre avertissement.

Décomposition du message d’erreur 70000 invalid grant

Lorsque vous êtes confronté à l’erreur AADSTS70000 invalid grant, vous avez en réalité affaire à deux éléments clés du message. Le premier est le code d’erreur lui-même, « AADSTS70000 ». Ce code signale spécifiquement un problème lié aux octrois OAuth dans le cadre d’authentification de Microsoft.

Le second élément est la raison, généralement libellée « invalid_grant » ou accompagnée d’un message du type « grant is invalid or malformed ». Il indique que le serveur n’a pas pu accepter la demande de jeton, généralement en raison de mauvaises configurations, de stratégies de sécurité ou de problèmes liés à la structure de l’octroi.

Si cette erreur apparaît dans les journaux de connexion Azure, elle peut parfois contenir des détails supplémentaires, comme « refresh token expired » ou « redirect URI mismatch ». Apprendre à reconnaître ces schémas vous aide à distinguer rapidement les erreurs utilisateur, les problèmes d’inscription d’application et les défaillances de configuration plus profondes du service. Vous réduisez ainsi le temps de diagnostic et vous orientez directement vers la documentation ou les canaux d’assistance Microsoft les plus utiles.

Quelles sont les causes de l’erreur 70000 invalid grant ?

Voici les causes les plus fréquentes de l’erreur AADSTS70000 invalid grant. Chacune est liée à la manière dont OAuth et Azure AD gèrent les jetons, la sécurité et les paramètres d’inscription des applications :

• Octrois OAuth mal formés ou expirés : les jetons d’accès et d’actualisation invalides ou expirés sont une cause majeure. Si un jeton est utilisé après sa date d’expiration ou s’il a été altéré en transit, Azure AD le rejette immédiatement.
• URI de redirection incorrects ou paramètres client non concordants : de légères différences dans l’URI de redirection enregistré (même une barre oblique manquante) peuvent interrompre le flux. La modification des informations d’une application sans mise à jour des paramètres Azure AD est une cause fréquente.
• Problèmes liés aux jetons d’actualisation : tenter de réutiliser un jeton d’actualisation révoqué, ou un jeton expiré ou émis pour un autre client, déclenche cette erreur. Il arrive que les administrateurs renouvellent des secrets ou réinitialisent des mots de passe, invalidant ainsi ces jetons par inadvertance.
• Interruption par les stratégies d’accès conditionnel et MFA : si une règle MFA ou de conformité de l’appareil intervient en cours de flux, en particulier pour les comptes de service ou les processus en arrière-plan, l’octroi est refusé sans explication claire. C’est un cas subtil qui déroute souvent même les professionnels aguerris. Vous souhaitez approfondir les stratégies d’accès conditionnel et les problèmes de confiance ? Consultez cette discussion sur les lacunes des stratégies et les bonnes pratiques.
• Incompatibilités de consentement ou d’étendues : lorsque des autorisations sont révoquées, partiellement consenties ou que des étendues d’application sont dépréciées, des intégrations qui fonctionnaient auparavant peuvent soudainement échouer. Les administrateurs et les développeurs qui intègrent des applications tierces doivent vérifier que les autorisations requises et le consentement administrateur sont toujours en place. Pour une analyse approfondie du risque lié au consentement OAuth dans Entra ID, consultez cette page.

Pistes de résolution pour l’erreur 70000 invalid grant

1. Vider les jetons en cache et se réauthentifier : La solution la plus rapide en cas de problème de jeton ou de session consiste à déconnecter puis reconnecter le compte ou le service concerné. Pour Power Automate, Outlook et les applications similaires, une déconnexion puis une reconnexion manuelles peuvent forcer un nouveau flux OAuth et résoudre les erreurs invalid_grant.
2. Vérifier et corriger les URI de redirection : Rendez-vous dans le portail Azure et vérifiez que l’URI de redirection de votre inscription d’application correspond exactement à celui envoyé par l’application ou le connecteur. Un simple caractère en trop suffit à faire échouer l’authentification lorsque Azure valide la demande.
3. Valider l’inscription d’application et les secrets client : Assurez-vous que les modifications récentes de l’inscription d’application, les rotations de secrets et les changements d’autorisations sont bien à jour. Les secrets client expirés ou incohérents sont un véritable fléau silencieux pour les intégrations en cours.
4. Examiner les stratégies d’accès conditionnel et le consentement : Auditez vos stratégies d’accès conditionnel à la recherche d’exclusions trop larges ou de lacunes en matière de conformité des appareils : elles peuvent interrompre des flux sans aucun message d’erreur explicite. Resserrez les flux de consentement des utilisateurs et vérifiez que le consentement administrateur reste appliqué là où il est nécessaire. Pour les stratégies de gouvernance, consultez ce guide approfondi sur les bonnes pratiques de sécurité.
5. Mettre à jour les étendues d’autorisation : Vérifiez à nouveau les étendues d’autorisation demandées par votre application ou votre automatisation. Les étendues changent parfois de nom ou sont dépréciées, en particulier dans Microsoft Graph. Assurez-vous que tout est cohérent entre le code de l’application, l’inscription dans le portail et l’historique des consentements.
6. Forcer la purge des jetons après des changements de sécurité : Si des jetons ont pu être compromis ou si vous venez de modifier vos stratégies de mot de passe, utilisez Intune ou le portail Azure pour révoquer toutes les sessions actives et imposer une nouvelle connexion à l’ensemble des utilisateurs et des automatisations. Pour en savoir plus sur la lutte contre les attaques persistantes par consentement, consultez ce guide sur les risques liés aux attaques par consentement dans Entra ID et leurs mesures d’atténuation.

Problème Power Automate : résoudre les échecs d’authentification invalid_grant

1. Reconnecter ou mettre à jour les connexions de données concernées : Si votre flux renvoie l’erreur 70000, commencez par ouvrir le flux dans Power Automate, repérer les connexions affichant un avertissement et les reconnecter simplement. Le service est ainsi contraint d’obtenir un nouveau jeton à partir des identifiants les plus récents.
2. Vérifier les autorisations de l’utilisateur et la validité des identifiants : Assurez-vous que l’utilisateur associé à votre flux dispose des droits d’accès nécessaires à la source de données. Si un compte utilisé dans le flux est désactivé, si son mot de passe a expiré ou si les exigences d’authentification multifacteur ont changé, les échecs d’authentification persisteront.
3. Valider les étendues d’autorisation requises : Vérifiez que les étendues accordées correspondent bien à ce dont votre flux a besoin pour lire ou envoyer des e-mails, créer des fichiers ou ajouter des éléments dans SharePoint. Ce point est particulièrement crucial pour les connecteurs Outlook et Teams.
4. Examiner les stratégies DLP et les restrictions des connecteurs : Les stratégies de prévention de la perte de données (DLP) peuvent interrompre silencieusement des flux si un connecteur passe de non bloqué à bloqué, ou s’il est reclassé par les administrateurs. Pour en savoir plus sur la création d’automatisations stables dans les limites DLP appropriées, consultez ce guide sur les stratégies DLP destiné aux développeurs Power Platform.
5. Distinguer les échecs transitoires des échecs persistants : Il arrive que l’erreur 70000 provienne d’une interruption brève ou d’un incident ponctuel du service. Un échec isolé suivi d’une reprise n’est généralement pas alarmant. En revanche, si l’erreur persiste, recherchez les problèmes d’autorisations de connexion et d’étendues de consentement dans l’ensemble de votre locataire.
6. Examiner la configuration de gouvernance : Les lacunes dans la gouvernance des environnements ou des identités peuvent laisser les risques d’authentification s’installer progressivement. Pour des conseils sur la gouvernance de Power Platform, reportez-vous à cet aperçu des bonnes pratiques.

Connexion Azure 70000 : utiliser les journaux Azure AD et l’audit pour le diagnostic

1. Commencer par les journaux de connexion Azure AD : Accédez aux journaux de connexion du portail Azure, filtrez les échecs portant le code « AADSTS70000 » et examinez la raison de l’échec, l’application cliente et l’adresse IP source. Cela permet de déterminer si le problème vient de l’utilisateur, de l’application ou d’une erreur de configuration.
2. Analysez les comportements liés aux jetons et aux clients : Recherchez les erreurs récurrentes liées au même utilisateur, à la même entité de service ou à la même application. Des erreurs « invalid grant » répétées après un événement planifié, comme la rotation d’un secret, pointent souvent vers des stratégies de jetons mal alignées ou vers des jetons d’actualisation arrivés à expiration.
3. Exploitez les journaux d’audit Azure AD pour disposer d’un contexte plus large : Croisez les échecs de connexion avec les journaux d’audit Azure AD. Ils révèlent les modifications apportées aux inscriptions d’applications, les mises à jour des stratégies d’accès conditionnel et les éventuelles révocations massives de jetons. Identifier un changement survenu juste avant l’apparition des erreurs peut vous mener directement à la cause racine.
4. Recourez aux outils d’audit avancés : Pour des investigations plus larges dans Microsoft 365, des outils comme Microsoft Purview Audit offrent une rétention étendue et des signaux détaillés utiles à l’analyse forensique. Pour apprendre à configurer et à utiliser ces outils, consultez cet aperçu de Purview Audit.
5. Renforcez la gouvernance pour une stabilité durable : Une bonne gouvernance permet d’éviter les ruptures silencieuses et la dérive progressive des stratégies au fil du temps. Imposez des garde-fous avec Azure Policy et surveillez les exceptions. Pour une stratégie complète, consultez le guide de gouvernance d’entreprise Azure.

Synchronisation horaire et décalage d’horloge : la cause cachée des erreurs OAuth invalid grant

L’une des causes les plus souvent négligées des erreurs invalid grant AADSTS70000 est tout simplement un désalignement de l’horloge système, plus connu sous le nom de décalage d’horloge (clock skew). Lorsque votre poste client et les serveurs de Microsoft ne s’accordent pas sur l’heure actuelle, les jetons OAuth et les codes d’autorisation peuvent sembler expirés ou pas encore valides, même si le reste de la configuration est correct.

Le problème est particulièrement délicat dans les environnements virtualisés ou cloud, où les systèmes fonctionnent avec des horloges légèrement désynchronisées. Les délais réseau ou la mise en veille des appareils peuvent aggraver la situation et faire échouer une tentative d’authentification pourtant valide, sans raison apparente.

La solution ? Synchronisez régulièrement tous les appareils avec un serveur NTP fiable. Configurez des corrections automatiques de l’heure sur vos contrôleurs de domaine, vos machines virtuelles et les postes des utilisateurs finaux. Rester à une minute ou deux de l’heure réelle vaut mieux que des échecs d’autorisation mystérieux. Pour une vue plus large des approches proactives de sécurité Microsoft 365 et Dynamics (y compris les contrôles adaptatifs), écoutez ce podcast Zero Trust by Design.