Lösung für den Fehler AADSTS700054 „Response Type Not Enabled“ in Azure AD-Apps

Von Mirko Peters · 2026-04-21

Sind Sie schon einmal auf den Fehler AADSTS700054 gestoßen und haben sich gefragt: „Was habe ich diesmal falsch gemacht?“ Damit sind Sie nicht allein. Dieser Fehler ist berüchtigt, weil er genau dann auftritt, wenn Sie versuchen, eine App über Azure Active Directory zu authentifizieren, besonders mit Microsoft 365, Dynamics 365 oder eigenen Single-Page-Apps. Im Kern bedeutet er, dass Ihre App nich

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

Sind Sie schon einmal auf den Fehler AADSTS700054 gestoßen und haben sich gefragt: „Was habe ich diesmal falsch gemacht?“ Damit sind Sie nicht allein. Dieser Fehler tritt besonders häufig genau dann auf, wenn Sie versuchen, eine App über Azure Active Directory zu authentifizieren, etwa mit Microsoft 365, Dynamics 365 oder eigenen Single-Page-Apps. Im Kern bedeutet er, dass Ihre App nicht für den angeforderten „Response Type“ eingerichtet ist, also etwa für ein ID-Token oder Zugriffstoken vom Autorisierungsendpunkt.

Dieser Leitfaden erklärt, warum der Fehler auftritt, und zeigt Ihnen, wie Sie ihn sowohl für ältere Anwendungen mit Implicit Grant als auch für moderne Setups mit MSAL.js und PKCE beheben. Außerdem erhalten Sie Best Practices für sichere Konfigurationen sowie Hinweise auf Community-Ressourcen und Tipps zur Navigation im Blog, damit Sie schnell Antworten finden. Ob Sie nun Legacy- oder moderne Apps analysieren: Am Ende wissen Sie genau, wie Sie diese häufige Authentifizierungshürde lösen und künftig vermeiden.

Die Ursachen des Fehlers AADSTS700054 verstehen

Der Fehler AADSTS700054 ist nicht einfach nur ein weiterer kryptischer Code von Microsoft. Er bedeutet im Grunde: „Deine App hat mich nach etwas gefragt, das sie nicht verwenden darf.“ Meist geht es um Response Types. Versucht Ihre Anwendung, ein Token von Azure AD anzufordern, ist aber für diesen Ablauf („Flow“), etwa den Implicit Grant, nicht konfiguriert, blockiert Azure die Anforderung und zeigt Ihnen diesen Fehler an.

Warum tritt das auf? In den meisten Fällen fehlen in der App-Registrierung die passenden Einstellungen für ID-Token, Zugriffstoken oder beides am Autorisierungsendpunkt. Ein Beispiel: Eine Single-Page-Application (SPA) fordert Token über den Implicit Flow an, obwohl dieser in Azure AD nicht aktiviert ist. Azure erkennt die Abweichung zwischen dem, was angefordert wird, und dem, was erlaubt ist, und Sie erhalten den Fehler AADSTS700054.

Fehlkonfigurationen passieren häufig, wenn Organisationen von älteren Authentifizierungsverfahren auf moderne Best Practices umstellen. Besonders gefährdet sind Unternehmen, die sowohl ältere Apps (die vielleicht noch Implicit Grant nutzen) als auch neuere Apps (die PKCE und den Authorization Code Flow verwenden sollten) betreiben. Wenn Sie die Cloud-Authentifizierung aktualisieren oder neue Microsoft-Dienste integrieren, steigt die Wahrscheinlichkeit, auf dieses Problem zu stoßen.

Wenn Sie diesen Fehler verstehen, erkennen Sie den Zusammenhang zwischen dem, was Ihr Code anfordert, und dem, was Ihre Azure-App verarbeiten kann. Deshalb zeigt Ihnen dieser Leitfaden im weiteren Verlauf, wie Sie die Token-Anforderungen Ihrer Anwendung an die Erwartungen der Microsoft Identity Platform anpassen. So sind Sie bei der Fehlersuche einen Schritt voraus.

Die empfohlene Lösung bei Problemen mit dem Response Type Implicit Grant aktivieren

Blockiert AADSTS700054 Ihre Integration, besteht die schnellste Abhilfe meist darin, die App-Registrierung mit den richtigen Response Types zu konfigurieren. Oft bedeutet das, die Einstellungen für den Implicit Grant zu aktivieren. Ihre App erhält damit im Grunde die Berechtigung, Token direkt vom Autorisierungsendpunkt anzufordern.

So gehen Sie im Azure-Portal vor: Öffnen Sie zuerst „App-Registrierungen“, suchen Sie die betroffene Anwendung und öffnen Sie den Bereich „Authentifizierung“. Suchen Sie dort den Bereich „Implicit Grant und Hybridflows“. Dort sehen Sie Kontrollkästchen für „Zugriffstoken“ und „ID-Token“. Aktivieren Sie die für Ihr Szenario passenden Optionen. In der Regel benötigen SPAs mindestens das Kontrollkästchen „ID-Token“, ältere Apps benötigen unter Umständen beide.

Aktivieren Sie aber nicht einfach alles und hoffen auf das Beste! Aktivieren Sie nur die Optionen, die Ihre App tatsächlich benötigt, und behalten Sie dabei die Sicherheit im Blick. Fordert Ihre App Token über den Autorisierungsendpunkt an, wie es die meisten browserbasierten Apps tun, sind diese Einstellungen erforderlich. Bei anderen Apps, besonders bei solchen, die auf sicherere Abläufe wie PKCE umstellen, müssen Sie den Implicit Grant möglicherweise gar nicht anfassen.

Nachdem Sie diese Änderungen übernommen haben, verschwinden die meisten Probleme mit AADSTS700054 sofort. Falls der Fehler weiterhin auftritt, prüfen Sie noch einmal Ihre Berechtigungsbereiche, die Redirect-URIs und ob die Änderungen vollständig übernommen wurden. Damit haben Sie die Grundlage, diesen Fehler zu beheben, und Benutzer sowie Entwickler können wieder produktiv arbeiten.

Best Security Practices zur Vermeidung von Fehlkonfigurationen bei Response Types

Die Anpassung der Einstellungen für den Implicit Grant kann einen Fehler beheben, doch auf lange Sicht ist das nicht immer der sicherste Weg. Ein aktivierter Implicit Flow erhöht Ihr Sicherheitsrisiko, denn Tokens werden direkt in den Browser-Antworten zurückgegeben und lassen sich dadurch potenziell leichter abfangen. Deshalb empfehlen Microsoft und jeder sicherheitsbewusste Administrator moderne Alternativen wie den Authorization Code Flow mit PKCE für die meisten Szenarien, besonders für neue oder überarbeitete SPAs.

Wann sollten Sie den Implicit Grant also aktivieren? Kurz gesagt: nur dann, wenn Legacy-Apps oder Sonderfälle ihn zwingend erfordern. Stellen Sie für alle anderen Apps den Authorization Code Flow (mit PKCE) ein. So verlassen Tokens nicht die Adressleiste des Browsers, und die Angriffsfläche sinkt deutlich.

Organisationen, die Power Platform, Microsoft 365 und Dynamics 365 kombinieren, können es sich nicht leisten, bei diesen Best Practices nachlässig zu sein. Falsch konfigurierte Response Types unterbrechen nicht nur Anmeldungen, sondern können Angreifern Türen öffnen oder später Probleme mit der Compliance verursachen. Dieser Überblick zu Sicherheit und Governance in Power Platform zeigt, warum strikte Kontrollen und das Wissen um die verwendeten Flows so wichtig sind, besonders wenn Citizen Developer eigene Apps und Integrationen hinzufügen.

Das Wichtigste in Kürze: Aktivieren Sie nur, was benötigt wird, bevorzugen Sie nach Möglichkeit den Code Flow mit PKCE, und sichern Sie Ihre App-Registrierungen im Rahmen einer übergreifenden Governance-Strategie ab. Achten Sie darauf, dass alle Einstellungen zu den Sicherheitsrichtlinien passen, die Sie durchsetzen möchten. Ihr zukünftiges Ich (und Ihre Auditoren) werden es Ihnen danken.

Fehlerbehebung für AADSTS700054 in modernen Apps mit MSAL.js

Man könnte meinen, dass der Umstieg auf moderne Authentifizierungsbibliotheken wie MSAL.js v2+ und PKCE Sie von „Fehlern aus der alten Zeit“ wie AADSTS700054 befreit, oder? So einfach ist es nicht. Selbst moderne Single Page Applications können ins Stolpern geraten, wenn ihre App-Registrierung oder clientseitige Konfiguration nicht den aktuellen Best Practices entspricht.

Der größte Verursacher? Veraltete Annahmen. Entwickler steigen in MSAL.js ein, behalten aber alte Redirect-URIs bei oder fordern versehentlich Response Types wie id_token an, die in Azure AD nicht aktiviert sind. Das gilt besonders dann, wenn das App-Manifest aus einem anderen Projekt kopiert wurde. Die Folge: Azure AD gibt diesen gefürchteten Fehler zurück, sobald Ihre App den Authentifizierungsablauf startet.

Wie können Sie das debuggen? Öffnen Sie die Entwicklertools Ihres Browsers, wechseln Sie zum Tab Netzwerk und beobachten Sie die Autorisierungsanfrage. Prüfen Sie genau, ob Ihr response_type zu den Flows passt, die Ihre Azure-App tatsächlich akzeptiert. Wenn Sie Anfragen für Tokens sehen, die nicht ordnungsgemäß aktiviert sind, gehen Sie zurück zum Azure-Portal und passen Sie Ihre App-Registrierung entsprechend an.

Denken Sie daran: Mit MSAL.js v2 und PKCE müssen Sie den Implicit Flow in der Regel gar nicht aktivieren. Wenn Ihre App dennoch fehlschlägt, suchen Sie nach fest codierten „Implicit“-Einstellungen, Tippfehlern in Redirect-URIs oder falschen Grant Types. Eine sorgfältige Prüfung der Konfiguration, sowohl auf Azure- als auch auf Client-Seite, behebt die meisten Probleme. Das ist vielleicht nicht spektakulär, aber gezielte Fehlersuche spart Stunden des Ratens.

Migration von Legacy-Anwendungen vom Implicit Grant zu PKCE

Bereit, den Implicit Flow endgültig hinter sich zu lassen? Gute Entscheidung. Die Migration zu PKCE (Proof Key for Code Exchange) ist inzwischen der Goldstandard, und Microsoft empfiehlt sie ausdrücklich. Doch seien wir ehrlich: Die Migration einer produktiven App mit Benutzern ist nie nur das Umlegen eines Schalters. Sie brauchen einen Plan, der Ausfallzeiten vermeidet, Anmeldeunterbrechungen minimiert und alle auf dem Laufenden hält.

Der erste Schritt ist, alle aktuellen App-Registrierungen mit Implicit Grant zu erfassen und zu bewerten. Testen Sie anschließend den neuen PKCE-basierten Flow in einer Staging-Umgebung. Dazu gehört, die App auf den Authorization Code Flow umzustellen, Redirect-URIs zu aktualisieren und Client-Konfigurationsdateien anzupassen (etwa beim Ersetzen von MSAL.js oder ADAL.js). Durchlaufen Sie die vollständigen Anmelde- und Abmeldezyklen sowie die Erneuerung von Tokens. Stellen Sie sicher, dass es für alle Benutzertypen funktioniert.

Bevor Sie in der Produktivumgebung umschalten, sollten Sie einen Rollback-Plan haben. Möglicherweise müssen Sie beide Flows vorübergehend aktiviert lassen, falls die Migration nicht reibungslos verläuft. Kommunizieren Sie klar mit Ihren Benutzern: Überraschungen mögen sie nicht, besonders dann nicht, wenn ihre Arbeit ins Stocken gerät, weil sich die Anmeldung ohne Ankündigung geändert hat.

Achten Sie zum Schluss auch auf Probleme wie fehlgeschlagene Token-Erneuerungen oder unterbrochene aktive Sitzungen nach der Migration. Planen Sie Updates nach Möglichkeit für Zeiten mit geringer Auslastung. Sie möchten mehr darüber erfahren, wie Sie diese Umstellungen im Betrieb umsetzen? Einige Ressourcen verweisen zwar weiter, aber in den aktuellen Podcasts zu Microsoft 365 Copilot und Architektur finden Sie immer wieder indirekte Hinweise zum Change Management in Unternehmen (siehe aktuelle Diskussionen hier).

Vertrauenswürdige Blogs wie den von Nishant Rana finden: verlässliche Lösungen

• Nishant Rana’s Weblog: Eine erste Anlaufstelle, wenn Probleme mit der Azure-AD-Integration auftreten. Nishant behandelt detaillierte Szenarien, schrittweise Lösungen und auch Spezialfälle für Dynamics 365 und Power Platform. Seine klaren Anleitungen nehmen den komplizierten Authentifizierungsfehlern viel von ihrem Schrecken.
• KingswaySoft MVP Blog: Dieser von MVPs betriebene Blog ist für praxisnahe Tipps zur CRM-Datenintegration bekannt. Er behandelt regelmäßig Grenzfälle bei der Authentifizierung, was für alle, die mit Azure AD und dem Microsoft-365-Ökosystem arbeiten, unverzichtbar ist.
• Top 100 CRM Blogs: Kuratierte Listen wie diese machen die breitere technische Community sichtbar. So finden Sie Autorinnen und Autoren, die regelmäßig über Microsoft-Identität, Sicherheit und Fehlerbehebung schreiben. Wenn Sie Ihre Leseliste erweitern, steigt die Chance, eine Lösung für Ihren speziellen Fall zu finden.

Schnelle Suche und Archive nutzen, um aktuelle Beiträge zu Azure-AD-Problemen zu finden

• Schnellsuche nutzen: Die meisten seriösen technischen Blogs haben ein Suchfeld. Nutzen Sie es! Geben Sie etwa „AADSTS700054“, „Azure AD error“ oder „implicit grant“ ein, um sofort Beiträge und Anleitungen zu finden, die direkt zu Ihrem Problem passen. Das ist deutlich schneller als manuelles Durchstöbern.
• Archive und aktuelle Beiträge durchsehen: Wenn Sie Ihr Problem über die Suche nicht finden, blättern Sie durch die Archive der Website oder die gefilterten Listen mit den „neuesten Beiträgen“. Viele bewährte Anleitungen zur Fehlerbehebung stehen in älteren Inhalten. Manchmal enthält aber auch ein aktueller Beitrag genau die Lösung für neue Authentifizierungsänderungen in der Plattform von Microsoft.
• Filter kombinieren für Fortgeschrittene: Sie wollen es genauer? Kombinieren Sie Tag- oder Kategoriesysteme mit der Suche. Wenn Sie alle Beiträge zu „Azure AD“ filtern oder nach „App-Registrierung“ eingrenzen, verkürzen Sie Ihre Fehlersuche deutlich. Außerdem finden Sie so Probleme und Lösungen, die Ihnen sonst vielleicht entgangen wären.