AADSTS900561 : erreur « Endpoint Only Accepts POST »

By Mirko Peters · 2026-04-22 · Updated 2026-07-28

Comprendre l’erreur AADSTS900561 « endpoint only accepts POST », pourquoi elle se produit lors de la connexion à Microsoft Entra et comment la résoudre en toute sécurité.

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

Réponse rapide : l’erreur AADSTS900561 « endpoint only accepts POST » signifie qu’un point de terminaison d’authentification Microsoft Entra a reçu une requête utilisant une méthode non prise en charge. Vérifiez le flux de connexion de l’application, la gestion des redirections et l’URL exacte ouverte, plutôt que de modifier sans cesse les paramètres d’identité à l’échelle du locataire.

Vous avez déjà rencontré l’erreur AADSTS900561 en travaillant avec Microsoft Entra ID ou Azure Active Directory ? C’est celle qui affiche : « Endpoint only accepts POST requests. » Concrètement, votre application a tenté de communiquer avec le service d’authentification de Microsoft à l’aide d’une requête GET, alors que le serveur attend une requête POST. C’est un peu comme frapper à la porte de derrière alors qu’il fallait passer par l’entrée principale.

Cette erreur apparaît souvent lorsque vous concevez ou intégrez des applications pour Microsoft 365, Azure ou Power Platform. Elle se produit généralement pendant les flux de connexion ou lorsque vous tentez d’obtenir un jeton auprès de la plateforme d’identité de Microsoft. Comprendre ce qui déclenche l’erreur AADSTS900561 est essentiel, car elle vous indique directement où vos appels d’authentification ne respectent pas les exigences techniques de Microsoft. Voyons maintenant pourquoi cette erreur est levée et comment elle est liée à un autre code bien connu, AADSTS90056.

AADSTS90056 et AADSTS900561 : description de l’erreur et contexte

Avant de vous attaquer à l’erreur AADSTS900561, il est utile de bien comprendre ce à quoi vous avez affaire. AADSTS90056 et AADSTS900561 sont deux codes d’erreur émis par Microsoft Entra ID (anciennement Azure AD) lorsque la manière dont votre application communique avec les points de terminaison d’authentification pose problème. En résumé : AADSTS90056 signale généralement un paramètre d’authentification incorrect ou manquant, tandis qu’AADSTS900561 concerne précisément les méthodes HTTP, plus exactement l’utilisation de GET alors que POST est requis.

Microsoft Entra ID applique des règles de protocole strictes pour les échanges de jetons et les flux d’authentification, souvent construits autour d’OAuth 2.0. Lorsque votre application doit obtenir un jeton en appelant le point de terminaison /token, Microsoft attend une requête POST. Il ne s’agit pas d’un caprice : les requêtes POST permettent d’envoyer des données sensibles de manière sécurisée dans le corps de la requête, et non dans l’URL, ce qui réduit le risque de fuite et d’enregistrement accidentel dans les journaux.

Les requêtes GET, en revanche, sont des livres ouverts. Elles exposent vos informations directement dans l’URL, visibles par quiconque ou par tout proxy situé sur le trajet. C’est un problème de sécurité, en particulier pour les services d’entreprise qui gèrent des identités et des données sensibles. C’est pourquoi la plateforme d’identité de Microsoft impose POST pour toute action impliquant l’échange de secrets, de codes ou d’informations utilisateur. Si vous envoyez une requête GET, la plateforme la détecte et bloque la requête avec l’erreur AADSTS900561. Comprendre ce contexte technique vous aide à saisir non seulement ce que vous avez fait de travers, mais aussi la raison de cette règle, et pourquoi elle est non négociable dans l’ensemble des services cloud de Microsoft.

En résumé, si vous rencontrez l’un de ces codes lors d’une authentification, votre application émet une requête qui ne respecte pas les règles. Avec le contexte de sécurité et de fiabilité du flux de protocole en toile de fond, vous saurez beaucoup plus clairement ce qu’il faut corriger et pourquoi cela compte dans des environnements applicatifs professionnels.

Causes courantes et solutions pour les problèmes d’authentification AADSTS900561

Si l’erreur AADSTS900561 apparaît, il y a fort à parier qu’une erreur se trouve dans la manière dont votre application appelle le point de terminaison de jeton de Microsoft. L’une des principales causes ? Un enregistrement d’application mal configuré ou un URI de redirection incorrect dans Azure AD. Si l’URI de redirection enregistré ne correspond pas à celui que votre application utilise réellement, ou s’il lui manque des éléments obligatoires, vous pouvez déclencher par inadvertance une requête GET au lieu de la requête POST attendue.

Autre erreur classique : la manière dont le flux d’authentification est codé. Certains développeurs utilisent GET par mégarde lors de l’appel du point de terminaison /token, notamment lorsqu’ils construisent les requêtes manuellement ou ont mal compris la bibliothèque utilisée. Avec OAuth 2.0 et Microsoft Entra, l’obtention finale du jeton doit toujours être envoyée en POST, jamais en GET. Si votre flux envoie une requête GET à cette étape, l’erreur AADSTS900561 apparaîtra immédiatement.

Alors, comment corriger le problème ? Commencez par vérifier attentivement vos URI de redirection, à la fois dans l’inscription de votre application sur le portail Azure et dans la configuration locale de votre application. Assurez-vous qu’elles correspondent parfaitement, jusqu’au protocole (http ou https) et au chemin. Si vous utilisez les bibliothèques MSAL ou ADAL, vérifiez que vous n’utilisez pas une ancienne version et que votre code ne remplace pas le comportement POST par défaut. Si vous utilisez votre propre code d’authentification, inspectez vos appels HTTP pour confirmer que le point de terminaison du jeton reçoit toujours une requête POST.

Besoin d’aide sur le code ? Voici un conseil rapide : en JavaScript, avec fetch ou axios, assurez-vous que votre appel à /token ressemble à method: 'POST'. Si vous voyez le message « endpoint only accepts post » dans vos journaux ou dans la console du navigateur, c’est le signal qu’il faut vérifier chaque étape de votre code entre l’autorisation et l’échange du jeton, surtout si votre application alterne entre la logique front-end et back-end. Pour aller plus loin sur les risques liés à l’identité et les correctifs de gouvernance concrets, découvrez cet épisode sur l’identité comme plan de contrôle de la sécurité Azure.

Débogage et bonnes pratiques pour prévenir les erreurs AADSTS900561

Voyons comment traquer cette erreur et faire en sorte qu’elle ne vous poursuive plus. Si vous exécutez une application monopage (SPA) avec React, Vue ou Angular, ouvrez les outils de développement de votre navigateur. Accédez à l’onglet Réseau, lancez votre flux de connexion et surveillez attentivement une requête GET adressée au point de terminaison /token. Dès que vous la repérez, vous avez trouvé le coupable.

Parfois, ce dysfonctionnement vient d’une bibliothèque d’authentification mal configurée. Avec MSAL.js, par exemple, utiliser loginRedirect alors que vous vouliez utiliser acquireTokenSilent, ou mal configurer la bibliothèque, peut provoquer l’envoi d’une requête GET au lieu d’une requête POST. Mettre MSAL.js à jour vers la dernière version et vérifier attentivement les paramètres d’initialisation peut vous épargner bien des maux de tête. Les frameworks sont exigeants, mais la documentation de Microsoft est très claire sur la nécessité d’utiliser POST pour les requêtes de jeton.

N’oubliez pas non plus vos journaux Azure. Consultez les journaux de connexion Azure AD pour obtenir les traces détaillées des requêtes. Vous y verrez quel point de terminaison a été appelé, quelle méthode a été utilisée et les éventuels indicateurs de non-concordance de protocole. Pour un diagnostic approfondi, des outils comme Fiddler permettent d’analyser le trafic HTTP ligne par ligne, et Application Insights peut retracer la pile d’appels jusqu’à l’origine du problème.

Mieux vaut prévenir que guérir. Testez toujours vos flux d’authentification dans les environnements de développement et de préproduction avant de les déployer en production. Assurez-vous que tout code qui échange un code d’autorisation contre un jeton s’exécute côté serveur, avec POST, comme le prescrit le guide OAuth 2.0. Échanger les codes dans le navigateur est un moyen classique de provoquer une erreur AADSTS900561 et d’ouvrir des failles de sécurité.

Si vous travaillez dans de grands environnements Microsoft 365 ou Azure, examinez votre approche de gouvernance. Entra ID sous-tend désormais un grand nombre d’accès critiques ; maintenir des stratégies rigoureuses et un code conforme aux bonnes pratiques de Microsoft facilite grandement les choses. Pour concevoir une gouvernance qui ne laisse rien passer entre les mailles du filet, cet épisode sur la stratégie de gouvernance d’entreprise Azure vaut vraiment le détour.

Et si votre application fait partie de Power Platform, ou utilise simplement des connecteurs, gérez vos identités et vos connecteurs avec soin pour éviter toute dérive architecturale et les erreurs d’autorisation inattendues. Vous trouverez des recommandations concrètes dans cette ressource : bonnes pratiques de sécurité et de gouvernance Power Platform.

En résumé ? Connaissez vos flux d’authentification, validez chaque requête et gardez vos outils à jour. Si une erreur parvient malgré tout à se glisser, vous saurez exactement où chercher et comment l’éliminer définitivement.

Liste de contrôle pratique

• Confirmez le résultat exact pour l’utilisateur et le périmètre concerné.
• Privilégiez la configuration ou le choix de communication le plus restreint et le plus sûr.
• Testez l’expérience avant un déploiement à grande échelle.
• Documentez les responsabilités, les actions de suivi et les points de revue.

Questions fréquentes

Quelle est la meilleure première étape ?

Identifiez le scénario utilisateur et le résultat précis que vous attendez. Cela évite les modifications inutiles et conduit à une mise en œuvre plus claire et plus fiable.

🎧 À écouter également

• Identity Governance in Entra fournit le contexte de gouvernance qui entoure l’administration des identités.
• Microsoft Entra Private Access – Simply Explained présente l’architecture moderne des identités et des accès.
• Privileged Identity Management (PIM) – Simply Explained apporte le contexte des accès privilégiés pour les administrateurs Entra.

Dernière revue : juillet 2026.