Erreur AADSTS900561 sur Outlook Web : résoudre « The endpoint only accepts POST requests » (Entra ID/Azure AD, OAuth2 /token)

Vous voyez « AADSTS900561: The endpoint only accepts POST requests. Received a GET request » en ouvrant Outlook sur le Web ? Suivez ce guide orienté réseau pour diagnostiquer, confirmer la cause et appliquer un correctif durable, sans bricolages hasardeux.

Sommaire

Problème observé : erreur AADSTS900561 lors de la connexion à Outlook sur le Web

Au moment de se connecter à Outlook sur le Web (Outlook.com ou Outlook dans Microsoft 365), l’écran d’authentification bascule sur une page d’erreur indiquant :

AADSTS900561: The endpoint only accepts POST requests. Received a GET request.

Le message réapparaît malgré des essais variés (vider le cache, autoriser les contenus tiers, changement de navigateur, ajout du site dans les paramètres hérités d’Internet Explorer, etc.).

Ce que signifie réellement le message

Dans les flux OAuth 2.0 de la plateforme d’identité Microsoft (Entra ID, ex‑Azure AD) :

La demande d’autorisation /authorize peut voyager en GET (ou POST).
L’échange de jeton sur /oauth2/v2.0/token doit impérativement être en POST avec un corps application/x-www-form-urlencoded.

L’erreur AADSTS900561 indique que le service d’identité a reçu une requête GET sur l’endpoint /token, qui n’accepte que des requêtes POST. Autrement dit, quelque chose dans le parcours réseau ou applicatif transforme, réécrit ou rejoue un POST en GET, ou redirige vers /token avec la mauvaise méthode.

Pourquoi cela arrive souvent avec Outlook sur le Web

Outlook sur le Web s’appuie entièrement sur l’authentification moderne via Entra ID. Toute anomalie réseau qui modifie les méthodes HTTP, intercepte de manière intrusive TLS, ou impose des redirections non conformes, se manifeste immédiatement à l’étape /token. C’est la raison pour laquelle on observe cette erreur plus fréquemment dans des environnements disposant d’un proxy, d’un pare‑feu applicatif ou d’une plate‑forme de sécurité (CASB, SWG, SASE) très interventionniste.

Causes les plus probables côté client et réseau

Inspection TLS / proxy explicite / passerelle cloud qui réécrit la méthode HTTP, bloque les POST ou interrompt la session chiffrée vers les domaines d’authentification Microsoft.
Extension navigateur, module de sécurité endpoint ou filtre anti‑traqueur qui manipule les requêtes (réécriture d’URL, blocage de fetch() ou de XMLHttpRequest, politique de cookies trop restrictive).
Mauvaise redirection dans une application ou un sign‑in initié par une URL obsolète (moins courant pour un accès direct à Outlook, mais possible en environnement hybride ou avec des pages de connexion personnalisées).
Proxy nécessitant une authentification qui renvoie un défi (407) sur une requête /token, entraînant des rejouements ou des dégradations de méthode et, in fine, un GET inattendu.

Plan d’action rapide pour restaurer l’accès

Tester en navigation privée et sans extensions, puis depuis un autre réseau (partage 4G/5G). Si le problème disparaît hors du réseau d’entreprise ou derrière un autre accès Internet, la cause est très probablement liée au proxy ou à l’inspection TLS.
Confirmer dans les DevTools que l’appel vers https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token part en POST et n’est pas converti en GET après un 30x.
Exempter de toute inspection TLS, réécriture et authentification proxy les domaines d’authentification Microsoft (voir les tableaux et exemples ci‑dessous).
Vérifier la connectivité réseau Microsoft 365 avec l’outil dédié (recherche : « Microsoft 365 Network Connectivity Test », site connectivity.office.com).
Mettre un contournement PAC en « DIRECT » pour ces domaines le temps d’identifier la règle fautive.
Escalader avec un journal HAR expurgé si, même en direct et sans inspection, l’appel /token échoue encore.

Dépannage détaillé pas‑à‑pas

Isoler immédiatement l’effet du réseau et des extensions

Ouvrez une fenêtre privée / InPrivate, désactivez toutes les extensions (bloqueurs, antivirus navigateur, assistant SSO, gestionnaire de mots de passe avec autofill agressif).
Tentez la connexion depuis un réseau distinct : point d’accès 4G/5G, box personnelle, VPN professionnel désactivé.
Si Outlook sur le Web fonctionne dès que l’on quitte le réseau d’entreprise ou l’agent de sécurité, vous tenez un indicateur fort d’un problème de proxy/inspection.

Contrôler la méthode HTTP dans les outils de développement

Objectif : voir si la requête /oauth2/v2.0/token part en POST et reste POST tout au long de la chaîne de redirections.

Ouvrez Outils de développement → Réseau (F12) dans Chrome/Edge/Firefox/Opera.
Activez Preserve log / Conserver les journaux et Disable cache / Désactiver le cache.
Refaites la connexion jusqu’à l’erreur.
Filtrez sur token et ouvrez l’élément Request :
- Méthode : doit être POST.
- Headers : Content-Type: application/x-www-form-urlencoded.
- Body : présence de grant_type, client_info, etc.
- Redirections : si vous voyez POST → 302 → GET aboutissant encore à /token, un équipement intermédiaire réécrit la méthode.
Exportez un HAR (clic droit → Save all as HAR with content) pour l’analyse et l’escalade. Important : expurgez toute donnée sensible (cookies, client_secret si utilisé, fragments d’URL contenant des codes d’autorisation).

Exclure inspection TLS, authentification proxy et réécriture

Pour l’auth Microsoft, il est recommandé d’acheminer le trafic en direct et intact (pas de déchiffrement, pas de modification) vers les endpoints ci‑dessous. Cela réduit la latence, évite les erreurs d’intégrité et respecte les exigences des flux OAuth 2.0.

Liste minimale d’exclusions réseau

Domaine / joker	Rôle	Action recommandée	Justification
`login.microsoftonline.com`	Endpoint d’autorisation et de jeton (Entra ID)	Pas d’inspection TLS, pas d’auth proxy, pas de réécriture	Préserver strictement les méthodes POST et le corps du formulaire
`login.windows.net`	Alias historique Entra ID	Exclure comme ci‑dessus	Certaines apps ou redirections l’utilisent encore
`login.microsoft.com`	Flux associés à l’identité	Exclure comme ci‑dessus	Évite les incohérences de redirection
`aadcdn.msauth.net`, `aadcdn.msftauth.net`	CDN d’assets d’authentification	Exclure de l’inspection et de l’auth proxy	Chargement fiable des scripts/iframes d’auth
`.msauth.net`, `.msftauth.net`	Ressources et iframes d’identité	Exclure	Évite le blocage de contenus tiers indispensables
`outlook.office.com`, `outlook.office365.com`	Service Outlook sur le Web	Optimiser / autoriser	Réduire la latence vers le service Exchange Online

Exemple de règle PAC pour un contournement ciblé

À utiliser temporairement ou comme règle permanente si votre politique le permet :

function FindProxyForURL(url, host) {
  var authHosts = [
    "login.microsoftonline.com",
    "login.windows.net",
    "login.microsoft.com",
    "aadcdn.msauth.net",
    "aadcdn.msftauth.net"
  ];
  for (var i = 0; i &lt; authHosts.length; i++) {
    if (dnsDomainIs(host, authHosts[i]) || shExpMatch(host, "*." + authHosts[i])) {
      return "DIRECT"; // Pas de proxy ni d'inspection
    }
  }
  if (dnsDomainIs(host, "outlook.office.com") || dnsDomainIs(host, "outlook.office365.com")) {
    return "PROXY proxy.corp.example:8080"; // ou DIRECT selon votre architecture
  }
  return "PROXY proxy.corp.example:8080";
}

Adaptez le nom et le port de votre proxy. Si vous utilisez WPAD ou une distribution de PAC via GPO/MDM, déployez après validation.

Vérifier la connectivité avec l’outil Microsoft

Exécutez l’outil « Microsoft 365 Network Connectivity Test » (site connectivity.office.com). En mode avancé, il signale :

Les domaines requis bloqués ou ralentis.
Les résolutions DNS suboptimales (chemin non local).
Des symptômes d’inspection ou de proxy reverse inapproprié.

Conservez le rapport pour vos archives de dépannage.

Gérer les environnements avec restrictions de tenant et passerelles cloud

Si vous appliquez Tenant Restrictions via des en‑têtes injectés par une passerelle, vous devez parfois déchiffrer TLS pour les domaines d’identité. Dans ce cas :

Limitez l’inspection uniquement aux hôtes d’identité et interdisez toute réécriture de méthode. L’injection d’en‑têtes ne doit pas altérer POST.
Testez avec et sans la politique TR active, pour confirmer que l’erreur n’est pas induite par le moteur d’injection.
Vérifiez la compatibilité de votre SWG/CASB/SASE : certains moteurs possèdent des features de « normalisation » HTTP capables de convertir un POST en GET lors de redirections 30x. Désactivez‑les pour les domaines d’identité.

Contournements utiles pendant l’investigation

Utiliser un navigateur portable sans extension ni profil pour valider rapidement.
Créer un groupe d’adresses dans le pare‑feu/proxy englobant les domaines d’auth Microsoft et placer une règle prioritaire « bypass/no‑decrypt ».
Mettre en place une liste d’exclusion MDM pour les agents de sécurité endpoint pouvant filtrer le trafic navigateur (ex. composant d’« isolation » ou de DLP).

Escalade vers Microsoft ou votre équipe réseau

Si, après exclusion de l’inspection et test direct, l’erreur AADSTS900561 continue :

Récupérez les identifiants de corrélation affichés dans le message d’erreur (correlation ID, timestamp, trace ID) et le tenant ID si visible.
Fournissez un HAR expurgé montrant : la requête vers /token, la méthode POST, l’éventuel 30x, la méthode qui devient GET, et l’hôte final.
Ajoutez des journaux proxy/pare‑feu corrélés (timestamp, règle touchée, action prise, module d’inspection activé).

Annexes pratiques

Exemple de test inoffensif avec cURL

Ce test ne délivre aucun jeton (valeurs factices), mais permet de vérifier que votre réseau laisse bien passer un POST vers /token sans le convertir en GET :

curl -i -X POST \
  "https://login.microsoftonline.com/common/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data "client_id=00000000-0000-0000-0000-000000000000&amp;grant_type=client_credentials&amp;scope=https%3A%2F%2Fgraph.microsoft.com%2F.default"

Vous devriez obtenir une réponse 400 Bad Request (paramètres invalides), mais la méthode doit rester POST. Si un GET apparaît dans des traces intermédiaires, un équipement le réécrit.

Exemple de checklist HAR pour l’équipe support

Le log contient‑il /oauth2/v2.0/token ?
La méthode est‑elle POST du début à la fin ?
Voit‑on un 302 suivi d’un GET sur /token ?
Quel hôte répond (exact login.*) ?
Des réponses proxy (407 Proxy Authentication Required) précèdent‑elles l’échec ?

Paramètres hérités Internet Explorer et Trusted Sites

Les réglages via inetcpl.cpl (zones de sécurité, « Trusted Sites ») n’ont, en général, aucun effet sur Chrome/Edge/Firefox/Opera s’ils ne sont pas imposés par stratégie d’entreprise. Privilégiez les exceptions réseau au niveau du proxy/pare‑feu plutôt que ces paramètres hérités.

Symptômes typiques et corrections associées

Symptôme	Cause probable	Vérification	Action corrective
Erreur AADSTS900561 immédiate après saisie du mot de passe	Inspection TLS réécrivant la méthode	DevTools : `POST → 302 → GET /token`	Exclure `login.microsoftonline.com` de l’inspection et de l’auth proxy
Boucle de connexion, rechargements incessants	Extension ou agent de sécurité bloque les cookies/iframes d’auth	OK en navigation privée et sans extensions	Désactiver/whitelister l’extension, autoriser `.msauth.net` et `.msftauth.net`
Fonctionne en 4G mais pas au bureau	Proxy d’entreprise altère les requêtes	Rapport de connectivité M365 signale un défaut	Appliquer la liste d’exclusion et les catégories Optimize/Allow

Questions fréquentes

Changer de navigateur ou vider le cache règle‑t‑il le problème ?

Rarement. Si la cause est un proxy/pare‑feu ou une inspection TLS, tous les navigateurs seront touchés. Ces actions peuvent toutefois aider à écarter une extension fautive ou un cache corrompu.

Pourquoi le message cite Outlook alors que l’origine est Entra ID ?

Parce que l’échec survient pendant l’authentification, avant que la session Outlook soit établie. Le service d’identité renvoie l’erreur, Outlook ne fait que l’afficher.

Puis‑je « forcer » le GET à être accepté ?

Non. Par conception et pour des raisons de sécurité/protocole, /token n’accepte pas les GET. Il faut corriger la cause de la réécriture.

Et si nous devons absolument inspecter le trafic pour des raisons de conformité ?

Alors limitez l’inspection aux domaines d’identité, bannissez toute réécriture de méthode et validez côté éditeur que votre solution supporte pleinement OAuth 2.0 sans altération (beaucoup de fournisseurs documentent une option « bypass for identity endpoints »).

Erreurs voisines à ne pas confondre

AADSTS700016 : application introuvable ou identifiant client incorrect. Sans rapport avec la méthode HTTP.
AADSTS900144 : demande invalide (paramètre manquant ou mal formé). Méthode POST intacte mais contenu incorrect.
AADSTS53003 : accès bloqué par une stratégie d’accès conditionnel. Authentification refusée par politique.

Dans AADSTS900561, la signature caractéristique est la réception d’un GET sur /token. Tout l’enjeu est de préserver le POST.

Bonnes pratiques à pérenniser

Maintenir à jour une liste d’URL/IP Microsoft 365 catégorisées (Optimize/Allow/Default) dans les politiques réseau.
Documenter une méthode de validation standard : DevTools, HAR, test cURL, rapport de connectivité.
Automatiser des tests de santé réguliers vers les endpoints d’identité pour détecter précocement toute régression de configuration.
Former les équipes à reconnaître qu’un GET sur /token est toujours anormal.

Résumé opérationnel

L’erreur AADSTS900561 n’est pas un bug d’Outlook : c’est Entra ID qui rejette une requête GET envoyée à un endpoint qui n’accepte que des POST. Dans l’immense majorité des cas, la résolution consiste à :

Vérifier dans les DevTools que /token reste en POST (sinon, suspecter une réécriture).
Exclure login.microsoftonline.com, ses alias et *.msauth.net / *.msftauth.net de toute inspection TLS, authentification proxy et manipulation.
Valider avec l’outil de connectivité Microsoft 365 et, au besoin, appliquer un contournement PAC en « DIRECT » le temps d’affiner les règles.
Escalader avec un HAR expurgé si le problème persiste hors inspection.

En procédant ainsi, vous rétablissez l’authentification moderne d’Outlook sur le Web sans sacrifier la sécurité, tout en alignant votre architecture réseau sur les bonnes pratiques Microsoft 365.

Erreur AADSTS900561 sur Outlook Web : résoudre « The endpoint only accepts POST requests » (Entra ID/Azure AD, OAuth2 /token)

Problème observé : erreur AADSTS900561 lors de la connexion à Outlook sur le Web