Erreur AADSTS900561 : The endpoint only accepts POST requests (Azure AD) – Diagnostic & correctifs

Impossible de se connecter à Outlook/Microsoft 365 ou Xbox Cloud Gaming ? Si Azure AD renvoie AADSTS900561 (« The endpoint only accepts POST requests »), ce guide pratique vous aide à diagnostiquer et corriger l’erreur côté navigateur, réseau et application.

Sommaire

Vue d’ensemble de la question

Plusieurs utilisateurs signalent une impossibilité soudaine de se connecter à des services Microsoft (Outlook / Microsoft 365 dans un navigateur, Xbox Cloud Gaming, applications métier intégrées à Azure AD, etc.). Le message d’erreur exact est AADSTS900561: The endpoint only accepts POST requests. Received a GET request. En clair, un point de terminaison (typiquement /oauth2/v2.0/token) qui ne traite que des requêtes HTTP POST a reçu une requête GET. Cette incohérence interrompt l’échange du code d’autorisation contre un jeton et casse la connexion.

Symptômes courants

Boucle de connexion infinie après saisie des identifiants.
Affichage direct d’une page d’erreur Azure AD portant le code AADSTS900561.
Connexion qui fonctionne en navigation privée mais pas en session normale.
Connexion qui fonctionne sur un autre navigateur ou un autre réseau (4G/5G) mais pas sur le réseau d’entreprise.
Échec systématique sur des postes protégés par un proxy/antivirus réseau, mais réussite sur un poste « neutre ».

Ce que signifie réellement l’erreur

Dans les flux OAuth 2.0 / OpenID Connect, le front-channel (navigateur) reçoit un authorization_code depuis l’/authorize. C’est ensuite l’application (ou la bibliothèque d’authentification) qui doit échanger ce code contre un access_token en POST vers /oauth2/v2.0/token. Si, pour une raison quelconque, cet échange est tenté en GET (copier-coller d’une URL, redirection mal gérée, extension qui réécrit la méthode, proxy/WAF qui normalize le trafic, etc.), Azure AD rejette l’appel et renvoie AADSTS900561.

Diagnostic express (15–60 minutes)

Tester un autre navigateur et une fenêtre privée (sans extensions). Si ça marche, suspecter cache/cookies/extension.
Tester sur un autre réseau (partage de connexion mobile). Si ça marche, suspecter proxy/VPN/WAF/CASB.
Tracer le trafic (F12 → Network). Confirmer qu’un GET touche /oauth2/v2.0/token au lieu d’un POST.
Si appli maison : vérifier la logique d’échange du code (serveur, méthode POST, en-têtes, redirections).

Pistes de diagnostic et solutions proposées

Angle de vérification	Actions recommandées	Pourquoi ?
Navigateur / client	Vider le cache et les cookies, ouvrir une fenêtre privée, tester un autre navigateur. Désactiver ou désinstaller les extensions susceptibles de réécrire les en‑têtes (bloqueurs de pub, proxy privés, antivirus Web).	Un cache corrompu ou une extension peut transformer la requête POST initiale en simple GET lors de la redirection.
URL et favoris	Supprimer ou mettre à jour les signets pointant vers `https://login.microsoftonline.com/...` contenant des paramètres query obsolètes.	Ouvrir directement une URL de jeton copiée/collée déclenche un GET. L’échange d’un authorization_code vers le jeton d’accès doit toujours se faire en POST, côté application.
Sites approuvés / paramètres de confidentialité	Ajouter `https://login.microsoftonline.com` aux sites approuvés : Panneau de configuration → Options Internet → Sécurité → Sites de confiance ou Options Internet → Confidentialité → Sites → Autoriser.	Certaines stratégies de sécurité forcent les redirections GET lorsqu’un domaine n’est pas approuvé.
Infrastructure réseau	Tester sans proxy, VPN, WAF ni passerelle CASB. Vérifier les règles qui modifient la méthode HTTP ou qui « sanitizent » les formulaires.	Un équipement de sécurité mal configuré peut bloquer ou convertir les requêtes POST.
Type de tenant / environnement	Préciser si l’environnement est 100 % cloud, hybride ou on‑premises (Exchange Server). Vérifier les URL de redirection OAuth dans Azure AD et, le cas échéant, dans le serveur ADFS ou le connecteur hybride.	Un endpoint hybride mal déclaré peut renvoyer l’utilisateur vers une page de connexion qui déclenche un GET.
Traçage	Utiliser F12 (Network), Fiddler ou Wireshark pour confirmer qu’un GET est vraiment envoyé à `/oauth2/v2.0/token` au lieu d’un POST.	Permet de localiser la conversion POST→GET et d’identifier le composant fautif.

Détails et procédures par angle

Navigateur / client : réinitialiser proprement

Chrome/Edge : Paramètres → Confidentialité et sécurité → Effacer les données de navigation. Cibler au minimum les cookies et données de sites pour login.microsoftonline.com, login.windows.net (legacy), microsoft.com, office.com, live.com. Redémarrer le navigateur.
Fenêtre privée : si la connexion réussit en navigation privée, c’est quasi confirmé côté cookies/extension. Réactivez les extensions une par une, en testant entre chaque activation.
Extensions à risque : bloqueurs de pubs/traqueurs, accélérateurs de téléchargement, gestionnaires de proxy, antivirus Web, gestionnaires de mots de passe non standards. Supprimez, ou ajoutez des exceptions pour login.microsoftonline.com.
Apps mobiles/clients lourds : certains injectent un webview. Mettez à jour l’app. Si l’erreur persiste uniquement dans l’app et pas dans le navigateur système, l’intégration du webview ou un SDK obsolète peut être en cause.

URL & favoris : bannir les ouvertures directes du token endpoint

Un réflexe courant consiste à mettre en favori une URL de connexion « qui marche ». Si cette URL contient des restes de paramètres (code=, session_state=, etc.), la rouvrir déclenche un GET direct vers un endpoint qui n’attend que des POST. Supprimez ces favoris et repassez par l’URL officielle de l’application (sa page d’accueil), qui relancera un authorize propre.

Sites approuvés & confidentialité : éviter les reconversions de méthode

Dans certains environnements verrouillés, les redirections cross-domain sont bridées. Ajoutez https://login.microsoftonline.com (et si nécessaire https://*.microsoftonline.com) aux sites de confiance et vérifiez que les cookies tiers ne sont pas bloqués pour ce domaine. Des politiques agressives de confidentialité peuvent convertir des POST en GET durant les enchaînements de redirections.

Réseau : proxies, WAF, CASB, VPN

Bypass de test : déconnectez le VPN, testez via 4G/5G. Si ça fonctionne hors réseau d’entreprise, ciblez proxy/WAF/CASB.
Normalisation de méthodes : certains équipements « rejouent » un POST en GET après une redirection 302. Exigez le respect de 307/308 (préservent la méthode) et désactivez toute règle qui modifie la méthode HTTP pour login.microsoftonline.com.
Taille de requête/Corps : les endpoints /token attendent application/x-www-form-urlencoded. Les politiques qui suppriment le corps (body stripping) conduisent à des comportements inattendus. Ajoutez une exception.
Inspection TLS : l’SSL inspection peut perturber les redirections. Testez en désactivant l’inspection pour les domaines Microsoft de login.

Tenant & hybride : redirections reply URL et fédération

En environnement hybride (ADFS, connecteurs), un misrouting peut exposer l’utilisateur à une page qui ne gère pas la suite de l’échange et retombe sur un GET. Vérifiez :

Les URL de redirection (reply URLs) dans l’enregistrement d’application (Azure AD).
La correspondance côté ADFS (si fédération) et les règles de revendications (claims).
Le scénario attendu (100 % cloud vs fédéré). Alignez les URL et le flux (Code+PKCE pour SPAs, Code pour applications confidentielles).

Traçage : comment prouver le POST→GET

Outils navigateur : F12 → Network. Filtrez sur login.microsoftonline.com et repérez un appel à /oauth2/v2.0/token. La colonne « Method » doit afficher POST. Si vous voyez GET, notez l’Initiator (qui a déclenché l’appel).
Fiddler (exemple de mise en évidence) : if (oSession.HostnameIs("login.microsoftonline.com") && oSession.uriContains("/oauth2/v2.0/token") && oSession.oRequest.headers.HTTPMethod != "POST") { oSession["ui-color"] = "red"; oSession["ui-comments"] = "Token endpoint appelé en " + oSession.oRequest.headers.HTTPMethod; }
Wireshark (filtre d’affichage) : http.request.method == "GET" && http.request.uri contains "/oauth2/v2.0/token"

Scénarios concrets et correctifs ciblés

Outlook sur le Web / Microsoft 365 (navigateur)

Ouvrir une fenêtre privée et tenter outlook.office.com. Si OK en privé, effacez cookies/site data pour office.com, microsoft.com, login.microsoftonline.com.
Désactiver temporairement les extensions (adblock, antivirus navigateur, proxy, gestionnaire de coupons).
Si l’entreprise utilise un proxy/WAF, tester via un réseau mobile. En cas de réussite, demander l’exclusion de login.microsoftonline.com des règles de method normalization / body stripping.

Xbox Cloud Gaming (navigateur)

Bien que la plupart des connexions Xbox utilisent un compte Microsoft (MSA), l’erreur peut apparaître sur des parcours mêlant comptes professionnels/éducation. Les mêmes correctifs s’appliquent : cookies propres, extensions coupées, réseau alternatif. Si l’erreur n’apparaît qu’avec un compte professionnel, escalader côté tenant Azure AD.

Applications internes (SPA/Front, Mobile, Desktop)

SPAs (React/Vue/Angular) : utilisez une bibliothèque officielle (p. ex. MSAL) qui orchestre correctement l’échange de code. Évitez tout window.location = "/oauth2/v2.0/token?...";. On n’ouvre jamais le token endpoint dans le navigateur.
Mobile / Desktop : si vous utilisez un embedded webview, préférez le navigateur système ou un broker d’identité. Vérifiez que les redirections ne sont pas converties en GET par le conteneur.

Bonnes pratiques de mise en œuvre (développeurs)

Échanger le code en POST côté serveur (ou via la bibliothèque)

Modèle minimal côté serveur avec POST application/x-www-form-urlencoded vers /oauth2/v2.0/token :

cURL (exemples)

# ❌ Mauvais : simule l'ouverture en GET (provoque AADSTS900561)
curl -v "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token?client_id=...&grant_type=authorization_code&code=..."

# ✅ Correct : POST avec corps url-encodé

curl -v -X POST "[https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token](https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token)" 
-H "Content-Type: application/x-www-form-urlencoded" 
--data "client_id=...&grant_type=authorization_code&code=...&redirect_uri=...&code_verifier=..."

Node.js (fetch)

import fetch from "node-fetch";
const params = new URLSearchParams({
  client_id: process.env.AZUREAD_CLIENT_ID,
  grant_type: "authorization_code",
  code: authCode,
  redirect_uri: process.env.AZUREAD_REDIRECT_URI,
  code_verifier: pkceVerifier
});
const res = await fetch("https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: params
});
const token = await res.json();

C# (.NET HttpClient)

using var http = new HttpClient();
var content = new FormUrlEncodedContent(new [] {
  new KeyValuePair<string,string>("client_id", clientId),
  new KeyValuePair<string,string>("grant_type", "authorization_code"),
  new KeyValuePair<string,string>("code", code),
  new KeyValuePair<string,string>("redirect_uri", redirectUri),
  new KeyValuePair<string,string>("code_verifier", codeVerifier),
});
var resp = await http.PostAsync("https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token", content);
var json = await resp.Content.ReadAsStringAsync();

Python (requests)

import requests
data = {
  "client_id": CLIENT_ID,
  "grant_type": "authorization_code",
  "code": code,
  "redirect_uri": REDIRECT_URI,
  "code_verifier": code_verifier
}
r = requests.post("https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token", data=data)
print(r.json())

Attention aux redirections 302 vs 307/308

Si votre application redirige après un POST, n’utilisez pas un 302 « générique » au risque que certains agents reconvertissent la méthode en GET. Préférez un 303 (vers une ressource GET) ou un 307/308 pour préserver la méthode lors d’une redirection légitime. Côté réseau, interdisez la réécriture de 307→302.

Jamais de token endpoint en front-channel

Évitez tout redirect utilisateur vers /token, tout <form action="/token" method="get"> et tout déclencheur GET vers cet endpoint. L’appel doit rester backchannel (serveur, bibliothèque, ou mécanisme prévu par le SDK).

Checklist « Admin » (tenant & connectivité)

Applications enregistrées : validez les URL de redirection (reply URLs), les types de comptes pris en charge et le flux (Code/PKCE).
Proxy/WAF : créez une exception « ne pas changer la méthode » pour *.microsoftonline.com et autorisez application/x-www-form-urlencoded sur /oauth2/v2.0/token.
CASB : désactiver les politiques de réécriture de formulaires pour les domaines d’identité Microsoft.
Inspection TLS : liste d’exceptions pour login.microsoftonline.com si des anomalies sont constatées.
Postes managés : GPO/MDM ne doivent pas bloquer cookies de première partie ni convertir les redirections en requêtes GET.

Modèles d’analyse et d’automatisation

Arbre de décision rapide

Si…	Alors…	Conclusion probable
Ça marche en navigation privée	Nettoyer cookies/site data, désactiver extensions	Problème local navigateur/extension
Ça marche sur réseau mobile	BYPASS proxy/WAF/CASB, ouvrir exception	Modification réseau de la méthode HTTP
Échec seulement sur l’appli interne	Vérifier l’échange du code (POST serveur)	Mauvaise implémentation du flux OAuth
Échec côté hybrides/fédérés	Vérifier ADFS/connecteurs & reply URLs	Redirection vers mauvaise page de connexion

Détection ciblée dans Fiddler (rappel)

if (oSession.HostnameIs("login.microsoftonline.com") 
 && oSession.uriContains("/oauth2/v2.0/token") 
 && oSession.oRequest.headers.HTTPMethod != "POST") {
    oSession["ui-bold"] = "true";
    oSession["ui-color"] = "tomato";
}

Étapes finales si le problème persiste

Collecter les métadonnées d’erreur : Request Id, Correlation Id, Timestamp affichées dans le message Azure AD.
Faire une capture d’écran complète avec l’URL visible et l’erreur.
Ouvrir un ticket Microsoft (portail d’administration ou support Xbox) en joignant ces éléments ; Microsoft pourra retrouver la trace précise dans ses logs pour déterminer qui a envoyé le GET.

Informations de fond utiles

L’erreur survient généralement juste après la phase d’autorisation OAuth 2.0 / OpenID Connect : le navigateur reçoit un authorization_code puis doit l’échanger en POST contre un access_token. Si l’utilisateur recharge la page, colle l’URL dans la barre d’adresse ou si un équipement réécrit la requête, Azure AD reçoit un GET et renvoie AADSTS900561.
Dans un code applicatif, assurez‑vous que l’échange du jeton se fait côté serveur (POST sur /oauth2/v2.0/token) et non dans le navigateur.
Historiquement, certaines redirections 302 pouvaient entraîner un changement de méthode de POST vers GET selon l’agent et les intermédiaires. Les codes 307/308 préservent la méthode.
Les équipements de sécurité qui « nettoient » les formulaires ou désactivent le corps des requêtes peuvent provoquer des comportements similaires (le serveur n’obtenant pas ce qu’il attend, un autre chemin se déclenche en GET).
Évitez toute tentative d’ouvrir un endpoint /token dans l’onglet du navigateur : ce n’est ni prévu ni supporté en front-channel.

FAQ express

Q : Pourquoi ça marche parfois puis échoue subitement ?
R : Une mise à jour d’extension, un changement de politique proxy/WAF ou un favori réutilisé peut convertir la méthode sans que vous n’en ayez conscience.

Q : L’erreur peut‑elle venir d’Azure AD lui‑même ?
R : Le message indique qu’Azure AD a reçu un GET là où il attend un POST. Dans l’écrasante majorité des cas, la cause se trouve côté client, réseau intermédiaire ou implémentation applicative.

Q : Que faire si l’appli est une SPA ?
R : Utilisez la bibliothèque officielle (p. ex. MSAL pour JavaScript) et laissez‑la gérer le flux Code+PKCE. Ne redirigez jamais manuellement vers /token.

Q : Un simple rafraîchissement peut‑il casser le flux ?
R : Oui. Rafraîchir une URL intermédiaire qui contient un code peut entraîner une navigation GET sur un endpoint prévu pour POST, d’où AADSTS900561.

Résumé en une phrase

Le correctif consiste à garantir que la requête d’échange de jeton reste une requête POST — en éliminant les favoris obsolètes, en vidant le cache, en désactivant les intermédiaires qui réécrivent les requêtes et, si nécessaire, en ajustant la configuration du tenant ou en soumettant les identifiants d’erreur au support Microsoft.

Annexes utiles

Vérifications rapides côté navigateur (pas à pas)

Ouvrez une fenêtre InPrivate/Incognito.
Essayez de vous connecter. Si ça fonctionne, revenez en fenêtre normale et supprimez uniquement les cookies des domaines d’identité Microsoft.
Désactivez toutes les extensions → réactivez‑les une par une.
Si l’échec persiste, basculez sur un autre navigateur (Chrome ↔ Edge ↔ Firefox).
Testez enfin via réseau mobile. Succès ici ? Concentrez‑vous sur le proxy/WAF/VPN.

Signatures typiques à repérer dans les traces

Appel à https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token avec Method: GET (au lieu de POST).
Redirection 302 immédiatement avant l’appel au token endpoint.
Absence d’en‑tête Content-Type: application/x-www-form-urlencoded et de corps dans la requête.
Réécriture par un équipement intermédiaire (Via/X-Forwarded-* inhabituels).

Exemple de réponse d’erreur JSON (côté client)

{
  "error": "invalid_request",
  "error_description": "AADSTS900561: The endpoint only accepts POST requests. Received a GET request."
}

Liste d’exclusion réseau suggérée (à adapter)

login.microsoftonline.com
*.microsoftonline.com
login.windows.net (héritage)
*.msauth.net, *.msauthimages.net (si applicable)

Pièges fréquents

Favori contenant un code= réutilisé plus tard.
Service Worker/extension qui intercepte fetch et réécrit method: "GET".
WAF appliquant une règle de « normalisation » globale des méthodes.
Copie d’une URL de jeton depuis une trace pour « tester » dans le navigateur.

Bonnes pratiques long terme

Documentez le flux d’authentification de vos applications et conservez un schéma de séquence.
Mettez en place un monitoring qui alerte si un GET touche un token endpoint.
Standardisez vos redirections (303/307/308) et bannissez la réécriture de méthodes dans les couches intermédiaires.
Utilisez et tenez à jour les SDKs officiels (MSAL, bibliothèques serveur).