De AADSTS70000-fout ‘invalid grant’ begrijpen in Microsoft Azure en M365

By Mirko Peters · 2026-04-21

De AADSTS70000-fout ‘invalid grant’ is een veelvoorkomende bron van hoofdpijn voor beheerders en ontwikkelaars die werken met Azure Active Directory en Microsoft 365-diensten. Je

Automatically translated with AI from the original post. Read the English original

De AADSTS70000-fout ‘invalid grant’ is een veelvoorkomende bron van hoofdpijn voor beheerders en ontwikkelaars die werken met Azure Active Directory en Microsoft 365-diensten. Je ziet deze fout vaak wanneer je systemen of automatiseringen koppelt via Power Platform, Outlook-add-ins of apps die vertrouwen op Microsoft-identiteitsstromen.

Kort gezegd betekent de AADSTS70000-fout dat er iets misging tijdens de authenticatie. Meestal gebeurt dit wanneer een app of gebruiker via OAuth een token probeert op te halen, maar de ‘grant’ niet langer geldig is. Dit kan een Power Automate-workflow lam leggen, een Outlook-integratie breken of het aanmelden bij elke app verstoren die Azure of Entra ID voor authenticatie gebruikt. Als je werkt in cloud-IT of app-ontwikkeling, is deze fout het serieus nemen waard, omdat hij wijst op authenticatie- en beveiligingsproblemen die je systemen volledig kunnen stilleggen.

Weten hoe en waar deze fout kan optreden, is essentieel voor snelle probleemoplossing en voorkomt die frustrerende momenten waarop iets ’s nachts zonder enige waarschuwing stopt met werken.

De onderdelen van de 70000 invalid grant-foutmelding uitgelegd

Wanneer je de AADSTS70000 invalid grant-fout tegenkomt, kijk je eigenlijk naar twee belangrijke onderdelen van de foutmelding. Het eerste is de foutcode zelf: ‘AADSTS70000’. Deze code wijst specifiek op problemen met OAuth-grants binnen het authenticatieraamwerk van Microsoft.

Het tweede onderdeel is de reden, meestal aangeduid als ‘invalid_grant’ of vergezeld van een bericht als ‘grant is invalid or malformed’. Dit betekent dat de server het tokenverzoek niet kon accepteren, meestal door verkeerde configuraties, beveiligingsbeleid of problemen met de structuur van de grant.

Als je deze fout ziet in de aanmeldingslogboeken van Azure, bevatten die soms extra details, zoals ‘refresh token expired’ of ‘redirect URI mismatch’. Door deze patronen te herkennen, kun je snel onderscheid maken tussen fouten van gebruikers, problemen met app-registraties en diepere misconfiguraties in diensten. Dat verkort de diagnosetijd en brengt je meteen bij de nuttigste documentatie of supportkanalen van Microsoft.

Wat veroorzaakt de 70000 invalid grant-fout?

Hieronder staan de meest voorkomende redenen waarom de AADSTS70000 invalid grant-fout kan optreden. Elk van die redenen hangt samen met hoe OAuth en Azure AD tokens, beveiliging en app-registratie-instellingen afhandelen:

• Onjuiste of verlopen OAuth-grants: Ongeldige of verlopen toegangs- en refreshtokens zijn een belangrijke oorzaak. Als een token wordt gebruikt na de vervaldatum of onderweg is gemanipuleerd, wijst Azure AD het direct af.
• Onjuiste redirect-URI’s of niet-overeenkomende clientinstellingen: Kleine verschillen in de geregistreerde redirect-URI (zelfs een ontbrekende schuine streep) kunnen de stroom verstoren. Het wijzigen van app-gegevens zonder de Azure AD-instellingen bij te werken, is een veelvoorkomende boosdoener.
• Problemen met refreshtokens: Proberen een ingetrokken refreshtoken opnieuw te gebruiken, of een token dat verlopen is of voor een andere client is uitgegeven, veroorzaakt deze fout. Soms roteren beheerders geheimen of resetten ze wachtwoorden, waardoor deze tokens per ongeluk ongeldig worden.
• Onderbreking door voorwaardelijke toegang- en MFA-beleid: Als een MFA- of apparaatcompliance-regel midden in de stroom wordt geactiveerd, vooral bij achtergrond- of serviceaccounts, wordt de grant geweigerd zonder veel uitleg. Dit is een subtiele oorzaak die zelfs ervaren professionals vaak op het verkeerde been zet. Wil je dieper ingaan op voorwaardelijke toegangsbeleidsregels en vertrouwensproblemen? Bekijk dan deze discussie over beleidslacunes en best practices.
• Mismatches in toestemming of scopes: Wanneer machtigingen worden ingetrokken, slechts gedeeltelijk zijn toegekend of app-scopes zijn verouderd, kunnen eerder werkende integraties ineens mislukken. Beheerders en ontwikkelaars die externe apps integreren, moeten controleren of de vereiste machtigingen en de beheerderstoestemming nog steeds aanwezig zijn. Voor een uitgebreide blik op het risico van OAuth-toestemming in Entra ID, zie deze pagina.

Oplossingsrichtingen voor de 70000 invalid grant-fout

1. Gecachte tokens wissen en opnieuw authenticeren: De snelste oplossing voor problemen met tokens of sessies is de betrokken account of service loskoppelen en opnieuw verbinden. Bij Power Automate, Outlook en vergelijkbare apps kun je door handmatig uit- en weer in te loggen een nieuwe OAuth-flow forceren, waarmee ongeldige grant-fouten vaak verdwijnen.
2. Redirect-URI's controleren en corrigeren: Ga naar de Azure Portal en controleer of de redirect-URI van je app-registratie exact overeenkomt met wat de app of connector verstuurt. Eén extra teken is genoeg om de hele authenticatie te laten mislukken wanneer Azure de aanvraag valideert.
3. App-registratie en clientgeheimen valideren: Zorg dat recente wijzigingen aan de app-registratie, het roteren van geheimen en wijzigingen in machtigingen goed zijn doorgevoerd. Verlopen of niet-overeenkomende clientgeheimen zijn een stille killer voor lopende integraties.
4. Voorwaardelijke toegangsbeleidsregels en toestemming controleren: Controleer je voorwaardelijke toegangsbeleidsregels op te ruime uitzonderingen of hiaten in apparaatcompliance. Die kunnen flows breken zonder duidelijke foutmelding. Verscherp de toestemmingsflows voor gebruikers en controleer of admin-toestemming nog waar nodig wordt afgedwongen. Voor governancestrategieën zie je deze uitgebreide gids over best practices voor beveiliging.
5. Machtigingsbereiken bijwerken: Controleer nogmaals de machtigingsbereiken (scopes) die je app of automatisering aanvraagt. Scopes veranderen soms van naam of worden verouderd, vooral in Microsoft Graph. Zorg dat alles overeenkomt tussen de appcode, de registratie in de portal en de toestemminggeschiedenis.
6. Tokens direct wissen na beveiligingswijzigingen: Als tokens mogelijk gecompromitteerd zijn of je net het wachtwoordbeleid hebt aangepast, gebruik dan Intune of de Azure Portal om alle actieve sessies in te trekken en alle gebruikers en automatiseringen opnieuw te laten aanmelden. Voor meer over het bestrijden van hardnekkige aanvallen op basis van toestemming lees je deze gids over risico's en maatregelen bij toestemmingsaanvallen in Entra ID.

Power Automate-probleem: fouten bij ongeldige grant-authenticatie oplossen

1. Betrokken gegevensverbindingen opnieuw verbinden of bijwerken: Als je flow de 70000-fout geeft, open je de flow in Power Automate, zoek je naar verbindingen met waarschuwingen en verbind je die opnieuw. Zo haalt de service een nieuw token op met de meest recente inloggegevens.
2. Gebruikersmachtigingen en geldigheid van inloggegevens controleren: Controleer of de gebruiker die aan je flow is gekoppeld de juiste toegang heeft tot de gegevensbron. Als een account in de flow is uitgeschakeld, het wachtwoord is verlopen of de MFA-vereisten zijn gewijzigd, krijg je aanhoudende authenticatiefouten.
3. Vereiste machtigingsbereiken valideren: Controleer nogmaals of de toegekende scopes overeenkomen met wat je flow nodig heeft om e-mails te lezen of te verzenden, bestanden aan te maken of items aan SharePoint toe te voegen. Dit is vooral belangrijk bij de Outlook- en Teams-connectors.
4. DLP-beleid en connectorbeperkingen controleren: Beleid voor gegevensverlies­preventie (DLP) kan flows stilletjes laten crashen als een connector van geblokkeerd naar niet-geblokkeerd gaat, of door beheerders opnieuw wordt ingedeeld. Voor meer informatie over stabiele automatiseringen binnen de juiste DLP-grenzen bekijk je deze DLP-beleidsgids voor Power Platform-ontwikkelaars.
5. Tijdelijke en aanhoudende fouten onderscheiden: Soms komt de 70000-fout voort uit kortstondige storingen of kleine haperingen in de dienst. Eén fout gevolgd door herstel is meestal geen reden tot zorg. Blijft de fout echter bestaan, begin dan met het nagaan van verbindingsmachtigingen en toestemmingsscopes in je tenant.
6. Governanceconfiguratie controleren: Hiaten in omgevings- of identiteitsgovernance kunnen authenticatierisico's na verloop van tijd laten insluipen. Voor tips over governance van Power Platform zie je dit overzicht met best practices.

Azure-aanmelding 70000: diagnose stellen met Azure AD-logboeken en auditing

1. Begin met de aanmeldingslogboeken van Azure AD: Ga in de Azure Portal naar de aanmeldingslogboeken en filter op mislukte aanmeldingen met code ‘AADSTS70000’. Controleer de reden van de fout, de clienttoepassing en het bron-IP-adres. Zo zie je of het probleem gebruikersgebonden, app-gebonden of een configuratieprobleem is.
2. Analyseer patronen in token- en clientgedrag: Zoek naar terugkerende fouten die gekoppeld zijn aan dezelfde gebruiker, serviceprincipal of app. Aanhoudende ‘invalid grant’-fouten na een gepland moment, zoals het roteren van een secret, wijzen vaak op niet-afgestemde tokenbeleidsregels of verlopen refresh tokens.
3. Gebruik Azure AD Audit Logs voor een bredere context: Combineer aanmeldingsfouten met de Azure AD-auditlogs. Zo zie je wijzigingen in app-registraties, updates van voorwaardelijk toegangsbeleid en mogelijke massale intrekkingen van tokens. Als je een wijziging vlak voor het begin van de fouten vindt, kom je vaak direct bij de hoofdoorzaak uit.
4. Gebruik geavanceerde auditingtools: Voor bredere onderzoeken binnen Microsoft 365 bieden tools zoals Microsoft Purview Audit langere bewaartermijnen en diepgaande signalen voor forensische analyse. Lees hoe je deze tools instelt en gebruikt in dit overzicht van Purview Audit.
5. Versterk governance voor stabiliteit op lange termijn: Goede governance voorkomt stille storingen en de geleidelijke afwijking van beleid in de tijd. Dwing guardrails af met Azure Policy en houd uitzonderingen goed in de gaten. Voor een uitgebreide strategie zie je de gids voor Azure enterprise governance.

Tijdsynchronisatie en clock skew: de verborgen oorzaak van OAuth-fouten ‘invalid grant’

Een van de meest over het hoofd geziene oorzaken van AADSTS70000-fouten ‘invalid grant’ is simpelweg een verkeerd ingestelde systeemklok, beter bekend als clock skew. Wanneer je clientcomputer en de servers van Microsoft het niet eens zijn over de huidige tijd, kunnen OAuth-tokens en autorisatiecodes verlopen lijken of nog niet geldig zijn, ook als al het andere klopt.

Dit is vooral lastig in virtuele of cloudomgevingen waarin verschillende systemen op iets uiteenlopende klokken draaien. Netwerkvertragingen of slaapstanden van apparaten kunnen het probleem nog verergeren, waardoor een geldige authenticatiepoging om onduidelijke redenen mislukt.

De oplossing? Synchroniseer alle apparaten regelmatig met een betrouwbare NTP-server. Stel automatische tijdcorrectie in op je domeincontrollers, virtuele machines en eindgebruikersapparaten. Binnen een minuut of twee van de ‘echte tijd’ blijven is beter dan mysterieuze grant-fouten, elke dag van de week. Voor een breder beeld van proactieve beveiligingsaanpakken voor Microsoft 365 en Dynamics (inclusief adaptieve controles) bekijk je deze Zero Trust by Design-podcast.