Der Fehler AADSTS70000 „Invalid Grant“ in Microsoft Azure und Microsoft 365 verstehen

Von Mirko Peters · 2026-04-21

Der Fehler AADSTS70000 „invalid grant“ ist für Administratoren und Entwickler, die mit Azure Active Directory und Microsoft 365 arbeiten, ein häufiges Ärgernis. Sie stoßen darauf vor allem beim Verbinden von Systemen oder Automatisierungen über Power Platform, Outlook-Add-ins oder Apps, die auf Microsoft-Identitätsabläufe angewiesen sind.

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

Cover: Fix Conditional Access Loopholes in Microsoft 365

Vereinfacht gesagt bedeutet der Fehler AADSTS70000, dass bei der Authentifizierung etwas schiefgelaufen ist. Meist versucht eine App oder ein Benutzer, über OAuth ein Token zu erhalten, der Grant ist jedoch nicht mehr gültig. Das kann einen Power Automate-Workflow lahmlegen, eine Outlook-Integration unterbrechen oder die Anmeldung an jeder App stören, die Azure oder Entra ID zur Authentifizierung nutzt. Wenn Sie in der Cloud-IT oder in der App-Entwicklung arbeiten, sollten Sie diesen Fehler ernst nehmen. Er weist auf Probleme bei Authentifizierung und Sicherheit hin, die Ihre Systeme schlagartig zum Stillstand bringen können.

Wer weiß, wie und wo dieser Fehler auftreten kann, kann schneller Fehler beheben. So vermeiden Sie die frustrierenden Momente, in denen etwas über Nacht ohne jede Vorwarnung nicht mehr funktioniert.

Die Bestandteile der Fehlermeldung 70000 „Invalid Grant“ im Detail

Wenn Sie auf den Fehler AADSTS70000 „invalid grant“ stoßen, enthält die Fehlermeldung im Wesentlichen zwei wichtige Teile. Der erste ist der Fehlercode selbst: „AADSTS70000“. Dieser Code verweist konkret auf Probleme mit OAuth-Grants im Authentifizierungsframework von Microsoft.

Der zweite Teil ist die Ursache, meist als „invalid_grant“ bezeichnet oder mit einer Meldung wie „grant is invalid or malformed“. Sie zeigt an, dass der Server die Tokenanforderung nicht akzeptieren konnte. Das liegt in der Regel an Fehlkonfigurationen, Sicherheitsrichtlinien oder an Problemen mit der Struktur des Grants.

Wenn Sie diesen Fehler in den Anmeldeprotokollen von Azure sehen, enthält er manchmal zusätzliche Details wie „refresh token expired“ oder „redirect URI mismatch“. Wenn Sie diese Muster erkennen, können Sie schneller unterscheiden, ob Benutzer einen Fehler gemacht haben, ob die App-Registrierung ein Problem hat oder ob eine tiefer liegende Fehlkonfiguration des Dienstes vorliegt. Das verkürzt die Diagnosezeit und führt Sie direkt zur hilfreichsten Dokumentation von Microsoft oder zum passenden Support.

Was verursacht den Fehler 70000 „Invalid Grant“?

Diese Ursachen treten bei dem Fehler AADSTS70000 „invalid grant“ am häufigsten auf. Jede davon hängt damit zusammen, wie OAuth und Azure AD Token, Sicherheit und die Einstellungen der App-Registrierung verarbeiten:

Fehlerhafte oder abgelaufene OAuth-Grants: Ungültige oder abgelaufene Zugriffs- und Aktualisierungstoken sind eine der Hauptursachen. Wird ein Token nach Ablauf verwendet oder auf dem Übertragungsweg manipuliert, lehnt Azure AD es sofort ab.
Falsche Umleitungs-URIs oder nicht übereinstimmende Clienteinstellungen: Schon kleine Abweichungen im registrierten Umleitungs-URI, sogar ein fehlender Schrägstrich, können den Ablauf unterbrechen. Häufig liegt die Ursache darin, dass App-Details geändert werden, ohne die Einstellungen in Azure AD anzupassen.
Probleme mit Aktualisierungstoken: Der Versuch, ein widerrufenes Aktualisierungstoken wiederzuverwenden, oder die Verwendung eines abgelaufenen oder für einen anderen Client ausgestellten Tokens löst diesen Fehler aus. Manchmal rotieren Administratoren Geheimnisse oder setzen Kennwörter zurück und machen dabei versehentlich diese Token ungültig.
Unterbrechung durch bedingten Zugriff und MFA-Richtlinien: Greift während des Ablaufs eine MFA- oder Gerätekonformitätsregel ein, vor allem bei Hintergrund- oder Dienstkonten, wird der Grant ohne große Erklärung verweigert. Das ist ein subtiler Fall, der auch erfahrene Fachleute oft ins Grübeln bringt. Möchten Sie die Richtlinien für bedingten Zugriff und Vertrauensprobleme genauer untersuchen? Lesen Sie dazu diese Diskussion über Richtlinienlücken und bewährte Methoden.
Abweichungen bei Zustimmung oder Bereichen: Werden Berechtigungen widerrufen, nur teilweise zugestimmt oder Appbereiche eingestellt, können bisher funktionierende Integrationen plötzlich fehlschlagen. Administratoren und Entwickler, die Drittanbieter-Apps einbinden, sollten prüfen, ob die erforderlichen Berechtigungen und die Administratorzustimmung noch vorhanden sind. Eine ausführliche Betrachtung des Risikos durch OAuth-Zustimmung in Entra ID finden Sie auf dieser Seite.

Lösungswege für den Fehler 70000 „Invalid Grant“

Zwischengespeicherte Token löschen und neu authentifizieren: Der schnellste Weg, Token- oder Sitzungsprobleme zu beheben, ist, das betroffene Konto oder den betroffenen Dienst zu trennen und erneut zu verbinden. Bei Power Automate, Outlook und ähnlichen Apps kann eine manuelle Abmeldung und erneute Anmeldung einen neuen OAuth-Ablauf erzwingen und ungültige Grant-Fehler beheben.
Umleitungs-URIs prüfen und korrigieren: Öffnen Sie das Azure-Portal und stellen Sie sicher, dass der Umleitungs-URI Ihrer App-Registrierung exakt mit dem übereinstimmt, was die App oder der Connector sendet. Schon ein einziges zusätzliches Zeichen kann die gesamte Authentifizierung scheitern lassen, wenn Azure die Anfrage prüft.
App-Registrierung und Clientgeheimnisse validieren: Stellen Sie sicher, dass alle aktuellen Änderungen an der App-Registrierung, Geheimnisrotationen und Berechtigungsänderungen vollständig übernommen sind. Abgelaufene oder nicht passende Clientgeheimnisse sind ein stiller Killer für laufende Integrationen.
Bedingte Zugriffsrichtlinien und Zustimmung prüfen: Überprüfen Sie Ihre Richtlinien für bedingten Zugriff auf zu weit gefasste Ausnahmen oder Lücken bei der Gerätekonformität. Diese können Ababläufe unterbrechen, ohne dass eine eindeutige Fehlermeldung erscheint. Verschärfen Sie die Zustimmungsabläufe für Benutzer und prüfen Sie, ob die Administratorzustimmung dort, wo sie nötig ist, weiterhin erzwungen wird. Zu Governance-Strategien finden Sie diesen ausführlichen Leitfaden zu Sicherheits-Best-Practices.
Berechtigungsbereiche aktualisieren: Prüfen Sie noch einmal die Berechtigungsbereiche, die Ihre App oder Ihre Automatisierung anfordert. Bereiche ändern manchmal ihre Namen oder werden eingestellt, besonders in Microsoft Graph. Stellen Sie sicher, dass Anwendungscode, Portal-Registrierung und Zustimmungsverlauf übereinstimmen.
Token nach Sicherheitsänderungen zwingend ungültig machen: Wenn Token möglicherweise kompromittiert wurden oder Sie gerade Kennwortrichtlinien aktualisiert haben, beenden Sie mit Intune oder dem Azure-Portal alle aktiven Sitzungen und fordern Sie für alle Benutzer und Automatisierungen eine neue Anmeldung an. Zum Umgang mit hartnäckigen, auf Zustimmung basierenden Zugriffsangriffen lesen Sie diesen Leitfaden zu Risiken und Gegenmaßnahmen bei Entra-ID-Zustimmungsangriffen.

Power-Automate-Problem: Fehlerbehebung bei Authentifizierungsfehlern vom Typ Invalid Grant

Betroffene Datenverbindungen neu verbinden oder aktualisieren: Wenn Ihr Ablauf den Fehler 70000 auslöst, öffnen Sie ihn zunächst in Power Automate, suchen Sie Verbindungen mit Warnungen und verbinden Sie diese einfach neu. Dadurch holt sich der Dienst mit den aktuellen Anmeldedaten ein neues Token.
Benutzerberechtigungen und Gültigkeit der Anmeldedaten prüfen: Stellen Sie sicher, dass der Benutzer, dem Ihr Ablauf zugewiesen ist, den richtigen Zugriff auf die Datenquelle hat. Ist ein im Ablauf verwendetes Konto deaktiviert, ist das Kennwort abgelaufen oder haben sich die MFA-Anforderungen geändert, treten dauerhafte Authentifizierungsfehler auf.
Erforderliche Berechtigungsbereiche validieren: Prüfen Sie genau, ob die erteilten Bereiche dem entsprechen, was Ihr Ablauf zum Lesen oder Senden von E-Mails, Erstellen von Dateien oder Hinzufügen von Elementen zu SharePoint benötigt. Das ist besonders bei den Connectors für Outlook und Teams entscheidend.
DLP-Richtlinien und Connector-Einschränkungen prüfen: Richtlinien zur Verhinderung von Datenverlust (Data Loss Prevention, DLP) können Abläufe unbemerkt unterbrechen, wenn ein Connector von freigegeben auf blockiert wechselt oder von Administratoren neu eingestuft wird. Weitere Informationen zu stabilen Automatisierungen mit den richtigen DLP-Grenzen finden Sie in diesem DLP-Richtlinien-Leitfaden für Power-Platform-Entwickler.
Vorübergehende und dauerhafte Fehler unterscheiden: Manchmal geht der Fehler 70000 auf kurzfristige Ausfälle oder Störungen des Dienstes zurück. Ein einzelner Fehler, dem eine Wiederherstellung folgt, ist meist kein Grund zur Sorge. Besteht der Fehler jedoch weiterhin, sollten Sie die Verbindungsberechtigungen und Zustimmungsbereiche in Ihrem Mandanten nachverfolgen.
Governance-Konfiguration prüfen: Lücken in der Governance von Umgebungen oder Identitäten können dazu führen, dass sich Authentifizierungsrisiken mit der Zeit einschleichen. Tipps zur Governance von Power Platform finden Sie in dieser Übersicht zu Best Practices.

Azure-Anmeldung 70000: Diagnose mit Azure-AD-Protokollen und Überwachung

Mit den Azure-AD-Anmeldeprotokollen beginnen: Öffnen Sie im Azure-Portal die Anmeldeprotokolle und filtern Sie nach Fehlern mit dem Code „AADSTS70000“. Prüfen Sie den Fehlergrund, die Client-App und die Quell-IP. So lässt sich eingrenzen, ob das Problem benutzer-, app- oder konfigurationsbezogen ist.
Token- und Client-Verhalten analysieren: Suchen Sie nach wiederkehrenden Fehlern, die demselben Benutzer, Dienstprinzipal oder derselben App zugeordnet sind. Auffällige „invalid grant“-Fehler nach einem geplanten Ereignis, etwa einer Rotation des Geheimnisses, deuten häufig auf nicht abgestimmte Token-Richtlinien oder abgelaufene Aktualisierungstoken hin.
Azure AD-Überwachungsprotokolle für den breiteren Kontext nutzen: Kombinieren Sie fehlgeschlagene Anmeldungen mit den Überwachungsprotokollen von Azure AD. So werden Änderungen an App-Registrierungen, Aktualisierungen von Richtlinien für bedingten Zugriff und mögliche Massenwiderrufe von Token sichtbar. Wenn Sie eine Änderung finden, die unmittelbar vor Beginn der Fehler erfolgte, kommen Sie oft direkt zur Ursache.
Erweiterte Überwachungstools einsetzen: Für umfassendere Untersuchungen in Microsoft 365 bieten Tools wie Microsoft Purview Audit eine verlängerte Aufbewahrung und detaillierte Signale für forensische Analysen. Wie Sie diese Tools einrichten und nutzen, erfahren Sie in dieser Übersicht zu Purview Audit.
Governance für langfristige Stabilität stärken: Gute Governance hilft, stille Ausfälle und die schleichende Abweichung von Richtlinien über die Zeit zu verhindern. Setzen Sie Leitplanken mit Azure Policy durch und überwachen Sie Ausnahmen. Eine umfassende Strategie finden Sie im Leitfaden zur Azure Enterprise Governance.

Zeitsynchronisierung und Uhrzeitabweichung: Die verborgene Ursache für OAuth-Fehler vom Typ „invalid grant“

Eine der am häufigsten übersehenen Ursachen für AADSTS70000-Fehler vom Typ „invalid grant“ ist eine einfache Abweichung der Systemuhr, besser bekannt als Clock Skew. Wenn sich Ihr Clientcomputer und die Server von Microsoft nicht über die aktuelle Uhrzeit einig sind, können OAuth-Token und Autorisierungscodes abgelaufen oder noch nicht gültig wirken, selbst wenn alles andere korrekt ist.

Besonders schwierig ist das in virtualisierten oder cloudbasierten Umgebungen, in denen verschiedene Systeme mit leicht unterschiedlich laufenden Uhren arbeiten. Netzwerkverzögerungen oder Ruhezustände von Geräten können das Problem verstärken und dazu führen, dass ein gültiger Anmeldeversuch ohne erkennbaren Grund fehlschlägt.

Die Lösung: Synchronisieren Sie alle Geräte regelmäßig mit einem zuverlässigen NTP-Server. Richten Sie automatische Zeitkorrekturen auf Ihren Domänencontrollern, virtuellen Maschinen und Endbenutzergeräten ein. Eine Abweichung von höchstens ein bis zwei Minuten von der „echten“ Uhrzeit verhindert rätselhafte Fehlschläge bei der Autorisierung. Einen breiteren Überblick über proaktive Sicherheitsansätze für Microsoft 365 und Dynamics, einschließlich adaptiver Kontrollen, bietet dieser Podcast zu Zero Trust by Design.