AADSTS900561: Endpoint Only Accepts POST Error

Von Mirko Peters · 2026-04-22 · Aktualisiert 2026-07-28

Erfahren Sie, was der Fehler AADSTS900561 „Endpoint only accepts POST“ bedeutet, warum er bei der Anmeldung mit Microsoft Entra auftritt und wie Sie ihn sicher beheben.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Kurzantwort: Der Fehler AADSTS900561 „Endpoint only accepts POST“ bedeutet, dass ein Authentifizierungsendpunkt von Microsoft Entra eine Anfrage mit einer nicht unterstützten Methode erhalten hat. Prüfen Sie den Anmeldeablauf der Anwendung, die Behandlung von Umleitungen und die genaue URL, die geöffnet wird, statt wiederholt die mandantenweiten Identitätseinstellungen zu ändern.

Sind Sie beim Arbeiten mit Microsoft Entra ID oder Azure Active Directory schon auf den Fehler AADSTS900561 gestoßen? Das ist der Fehler mit der Meldung „Endpoint only accepts POST requests.“ Vereinfacht gesagt bedeutet er: Ihre App hat versucht, per GET-Anfrage mit dem Authentifizierungsdienst von Microsoft zu kommunizieren, der Server erwartet aber eine POST-Anfrage. Das ist, als würden Sie an die Hintertür klopfen, obwohl Sie den Vordereingang nehmen sollten.

Dieser Fehler tritt häufig auf, wenn Sie Apps für Microsoft 365, Azure oder Power Platform entwickeln oder integrieren. Meist erscheint er bei Anmeldeabläufen oder wenn versucht wird, über die Identitätsplattform von Microsoft ein Token abzurufen. Es ist wichtig zu wissen, was den Fehler AADSTS900561 auslöst, denn er zeigt Ihnen genau, wo Ihre Authentifizierungsaufrufe nicht den technischen Vorgaben von Microsoft entsprechen. Als Nächstes sehen wir uns an, warum dieser Fehler ausgegeben wird und wie er mit einem anderen bekannten Fehlercode zusammenhängt: AADSTS90056.

AADSTS90056 und AADSTS900561: Fehlerbeschreibung und Hintergrund

Bevor Sie den Fehler AADSTS900561 beheben, sollten Sie genau wissen, womit Sie es zu tun haben. Sowohl AADSTS90056 als auch AADSTS900561 sind Fehlercodes, die Microsoft Entra ID (früher Azure AD) ausgibt, wenn die Kommunikation Ihrer App mit den Authentifizierungsendpunkten nicht stimmt. Kurz gesagt: AADSTS90056 weist meist auf einen fehlerhaften oder fehlenden Authentifizierungsparameter hin, während AADSTS900561 ausschließlich HTTP-Methoden betrifft, konkret dann, wenn GET verwendet wird, wo POST erforderlich ist.

Microsoft Entra ID setzt für Tokenaustausch und Authentifizierungsabläufe strikte Protokollregeln ein, die häufig auf OAuth 2.0 basieren. Wenn Ihre App ein Token über den /token-Endpunkt anfordern möchte, erwartet Microsoft eine POST-Anfrage. Das ist keine Schikane: Mit POST übertragen Sie vertrauliche Daten sicher im Anfragetext statt in der URL. Dadurch sinkt das Risiko von Datenlecks und versehentlicher Protokollierung.

GET-Anfragen dagegen sind offene Bücher. Sie legen Ihre Daten direkt in die URL, sodass jeder Beteiligte oder Proxy auf dem Weg sie einsehen kann. Das ist ein Sicherheitsproblem, besonders bei Unternehmensdiensten, die Identitäten und sensible Daten verwalten. Daher erzwingt die Identitätsplattform von Microsoft POST für alle Aktionen, bei denen Geheimnisse, Codes oder Benutzerdaten ausgetauscht werden. Senden Sie eine GET-Anfrage, erkennt die Plattform das und blockiert den Vorgang mit dem Fehler AADSTS900561. Wenn Sie diesen technischen Hintergrund kennen, verstehen Sie nicht nur, was falsch gelaufen ist, sondern auch, warum diese Regel existiert und warum sie in allen Microsoft-Cloud-Diensten nicht verhandelbar ist.

Kurz gesagt: Wenn bei der Authentifizierung einer dieser beiden Codes erscheint, stellt Ihre App eine Anfrage, die nicht den Regeln entspricht. Mit dem Hintergrundwissen zu Sicherheit und verlässlichem Protokollablauf erkennen Sie deutlich klarer, was Sie beheben müssen und warum das in professionellen App-Umgebungen wichtig ist.

Häufige Ursachen und Lösungen für Authentifizierungsprobleme mit AADSTS900561

Wenn AADSTS900561 auftritt, liegt praktisch immer ein Fehler in der Art vor, wie Ihre App den Token-Endpunkt von Microsoft anspricht. Eine der häufigsten Ursachen ist eine fehlerhafte App-Registrierung oder ein falscher Umleitungs-URI in Azure AD. Wenn der registrierte Umleitungs-URI nicht mit dem übereinstimmt, den Ihre App tatsächlich verwendet, oder wenn erforderliche Angaben fehlen, kann versehentlich eine GET-Anfrage statt der erwarteten POST-Anfrage ausgelöst werden.

Ein weiterer klassischer Fehler liegt im Code des Authentifizierungsablaufs selbst. Manche Entwickler verwenden beim Aufruf des /token-Endpunkts versehentlich GET, besonders wenn sie Anfragen manuell erstellen oder die verwendete Bibliothek falsch verstanden haben. Bei OAuth 2.0 mit Microsoft Entra sollte die finale Tokenanforderung immer als POST gesendet werden, niemals als GET. Sendet Ihr Ablauf an dieser Stelle eine GET-Anfrage, erscheint sofort der Fehler AADSTS900561.

Wie beheben Sie das Problem? Prüfen Sie zunächst Ihre Umleitungs-URIs sowohl in der Registrierung im Azure-Portal als auch in der lokalen Konfiguration Ihrer App. Achten Sie darauf, dass sie exakt übereinstimmen, bis hin zum Protokoll (http oder https) und zum Pfad. Wenn Sie die Bibliotheken MSAL oder ADAL verwenden, stellen Sie sicher, dass Sie keine veraltete Version einsetzen und kein eigener Code das standardmäßige POST-Verhalten überschreibt. Wenn Sie eigenen Authentifizierungscode nutzen, untersuchen Sie Ihre HTTP-Aufrufe und vergewissern Sie sich, dass der Token-Endpunkt immer mit einer POST-Anforderung angesprochen wird.

Sie brauchen Unterstützung beim Code? Hier ein kurzer Tipp: Achten Sie in JavaScript mit fetch oder axios darauf, dass Ihr Aufruf von /token in etwa so aussieht: method: 'POST'. Wenn Sie in Ihren Logs oder im Browser die Meldung „endpoint only accepts post“ sehen, sollten Sie jeden Schritt Ihres Codes zwischen Autorisierung und Token-Austausch prüfen, besonders wenn Ihre App zwischen Front-End- und Back-End-Logik wechselt. Ausführlicher zu identitätsbasierten Risiken und praxistauglichen Governance-Lösungen erfahren Sie in dieser Episode über Identität als Steuerungsebene in der Azure-Sicherheit.

Fehlerbehebung und bewährte Methoden zur Vermeidung von AADSTS900561-Fehlern

Sehen wir uns an, wie Sie diesen Fehler aufspüren und dafür sorgen, dass er nicht erneut auftritt. Wenn Sie eine Single-Page-App (SPA) mit React, Vue oder Angular betreiben, öffnen Sie die Entwicklertools Ihres Browsers. Wechseln Sie zum Tab Netzwerk, starten Sie Ihren Anmeldevorgang und achten Sie genau auf eine GET-Anforderung an den Endpunkt /token. Sobald Sie sie sehen, haben Sie den Verursacher gefunden.

Manchmal liegt der Fehler daran, dass Ihre Authentifizierungsbibliothek nicht richtig eingerichtet ist. In MSAL.js kann zum Beispiel die Verwendung von loginRedirect anstelle von acquireTokenSilent oder eine fehlerhafte Konfiguration der Bibliothek dazu führen, dass statt einer POST- eine GET-Anforderung ausgelöst wird. Ein Update auf die neueste MSAL.js-Version und eine Prüfung Ihrer Initialisierungseinstellungen können Ihnen viel Ärger ersparen. Frameworks sind eigen, aber die Microsoft-Dokumentation ist eindeutig: Token-Anforderungen müssen per POST erfolgen.

Werfen Sie außerdem einen Blick in Ihre Azure-Protokolle. Prüfen Sie die Anmeldeprotokolle von Azure AD auf detaillierte Anforderungsverläufe. Dort sehen Sie, welcher Endpunkt aufgerufen wurde, welche Methode verwendet wurde und ob Hinweise auf Protokollabweichungen vorliegen. Für eine tiefgehende Diagnose eignen sich Werkzeuge wie Fiddler, das den HTTP-Verkehr Zeile für Zeile aufschlüsselt, und Application Insights, das den Aufrufstapel direkt bis zur problematischen Stelle nachverfolgen kann.

Vorbeugen ist besser als Aufräumen im Nachhinein. Testen Sie Ihre Authentifizierungsabläufe immer zuerst in Entwicklungs- und Staging-Umgebungen, bevor Sie sie produktiv einsetzen. Stellen Sie sicher, dass jeder Code, der einen Autorisierungscode gegen ein Token austauscht, serverseitig und per POST läuft, so wie es der OAuth-2.0-Standard vorsieht. Der Austausch von Codes im Browser ist ein klassischer Weg, AADSTS900561 zu provozieren und Sicherheitslücken zu öffnen.

Wenn Sie in großen Microsoft 365- oder Azure-Umgebungen arbeiten, sollten Sie Ihren Governance-Ansatz überprüfen. Entra ID bildet inzwischen die Grundlage für viele kritische Zugriffe. Richtlinien straff zu halten und Ihren Code an den bewährten Methoden von Microsoft auszurichten, erleichtert die Arbeit deutlich. Informationen dazu, wie Sie eine Governance gestalten, bei der nichts durchrutscht, finden Sie in dieser Episode zur Azure-Governance-Strategie für Unternehmen, die sich lohnt.

Und wenn Ihre App Teil der Power Platform ist oder lediglich Konnektoren nutzt, verwalten Sie Identitäten und Konnektoren sorgfältig, um architektonische Abweichungen und unerwartete Berechtigungsfehler zu vermeiden. Praxisnahe Hinweise finden Sie in dieser Ressource: Bewährte Methoden für Sicherheit und Governance in der Power Platform.

Das Fazit: Kennen Sie Ihre Authentifizierungsabläufe, prüfen Sie jede Anforderung und halten Sie Ihre Werkzeuge aktuell. Sollte ein Fehler dennoch durchrutschen, wissen Sie genau, wo Sie suchen müssen, und wie Sie ihn dauerhaft beseitigen.

Praktische Checkliste

• Bestätigen Sie das genaue Ergebnis für die Benutzer und den betroffenen Umfang.
• Wählen Sie die engste sichere Konfiguration oder Kommunikationsoption.
• Testen Sie das Nutzungserlebnis, bevor Sie breit ausrollen.
• Dokumentieren Sie Verantwortlichkeiten, Folgemaßnahmen und Prüfpunkte.

Häufige Fragen

Was ist der beste erste Schritt?

Ermitteln Sie das Nutzerszenario und das konkrete Ergebnis, das Sie benötigen. So vermeiden Sie unnötige Änderungen und erhalten eine klarere, zuverlässigere Umsetzung.

🎧 Das könnte Sie auch interessieren

• Identity Governance in Entra bietet den Governance-Rahmen für die Identitätsverwaltung.
• Microsoft Entra Private Access – Simply Explained erläutert moderne Architekturen für Identität und Zugriff.
• Privileged Identity Management (PIM) – Simply Explained liefert den Kontext zu privilegiertem Zugriff für Entra-Administratoren.

Zuletzt überprüft: Juli 2026.