AADSTS900144-foutmelding oplossen in Azure AD

By Mirko Peters · 2026-04-21

Niemand wordt vrolijk van authenticatiefouten, maar de AADSTS900144-foutmelding over een ontbrekende parameter in Azure AD is een klassieke blokkade die zowel app-ontwikkelaars als IT-beheerders frustreert. In dit artikel lees je wat er precies achter die fout zit, wat je als eerste moet controleren en welke stappen je nodig hebt om gebruikers weer aan de slag te krijgen. We lopen de oorzaken en o

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

Cover: Fix Microsoft Teams Governance Sprawl with Enforced Decisions

Of je nu Microsoft 365, Azure, Power Platform of een andere oplossing ondersteunt die met Entra ID verbindt, je vindt hier tips voor zowel client-side als server-side oplossingen. Praktische probleemoplossing, best practices die geschikt zijn voor grote organisaties en extra links naar content over cloudgovernance helpen je om deze hoofdpijn de volgende keer te voorkomen wanneer deze fout weer opduikt.

Waarom krijg je “AADSTS900144” bij authenticatie in Azure AD?

De foutmelding “AADSTS900144: Request body must contain the following parameter” verschijnt wanneer er belangrijke gegevens ontbreken in een authenticatieverzoek dat naar Azure Active Directory (of Microsoft Entra ID) wordt gestuurd. Simpel gezegd zoekt Azure naar informatie zoals grant_type of client_id in je tokenverzoek, en vindt het die niet. Of de gegevens zijn er wel, maar ze zijn verkeerd opgemaakt of staan op de verkeerde plek.

Deze fout komt het vaakst voor tijdens OAuth 2.0-flows, vooral wanneer gebruikers of apps proberen in te loggen bij zakelijke cloudservices. Meestal ligt de oorzaak in de parameters in de requestbody die worden verstuurd bij het uitwisselen van een autorisatiecode voor een token. Als een verplichte parameter ontbreekt, verkeerd is gespeld of buiten de verwachte POST-body is geplaatst, zet Azure AD alles met de AADSTS900144-code direct stil.

Je kunt deze fout tegenkomen bij de integratie van zakelijke apps op maat, bij het registreren van nieuwe apps in Azure, of wanneer desktopclients (zoals Microsoft Teams) problemen ondervinden met authenticatie. Soms is het al genoeg om een kopieer-en-plakfout te maken of een app-registratie snel aan te passen om de parameters uit de pas te laten lopen. De foutmelding ziet er misschien cryptisch uit, maar het is Azure’s manier om te zeggen: “Ga terug, controleer je verzoek nog eens goed en los op wat ontbreekt.”

Voor wie met multi-tenant applicaties werkt: let op, verkeerde tenantcontext of verkeerde serviceendpoints kunnen voor vergelijkbare verwarring zorgen. Soms lijkt het dan alsof er een parameter ontbreekt, terwijl die gewoon naar de verkeerde plek wordt gestuurd. Wie deze mechanismen begrijpt, lost problemen sneller op en houdt het voor supportteams een stuk rustiger.

Veelvoorkomende problemen met parameters in de requestbody en snelle oplossingen

De AADSTS900144-fout komt bijna altijd neer op iets wat is weggelaten of op de verkeerde plek staat in je tokenverzoek. Belangrijke parameters zoals client_id en grant_type zijn de meest voorkomende boosdoeners. Als je app ook maar één verplichte parameter mist, wijst het tokeneindpunt van Azure AD het verzoek zonder pardon af. Controleer ook of je de HTTP POST-methode gebruikt, want GET en andere methoden werken hier niet.

Begin met controleren of je app verzoeken stuurt met het contenttype application/x-www-form-urlencoded. Het is verbazingwekkend hoe vaak een verkeerd contenttype ervoor zorgt dat Azure AD naar parameters zoekt die het niet kan lezen. Open vervolgens een willekeurige HTTP-tool (Postman, curl of zelfs Fiddler) en bekijk de ruwe body. Staan client_id, grant_type, client_secret en de overige parameters echt in de payload, en niet als querystringwaarden of verborgen in de headers?

Als je een app-registratie aanpast, houd er dan rekening mee dat de verwachte parameters kunnen verschillen per grant flow. Bij de autorisatiecode-grant moet je bijvoorbeeld ook code meesturen. Dat is niet altijd duidelijk, dus controleer je grant type altijd tegen de Azure-documentatie voordat je het als afgerond beschouwt.

Bij multitenant-apps moet je oppassen met verzoeken naar het /common-eindpunt wanneer je doeltenant een specifieke GUID of waarde nodig heeft. Anders is je “ontbrekende parameter” misschien gewoon een verkeerd geleid verzoek. Verkeerde URL’s, vooral in scenario’s met meerdere tenants, kunnen ook ervaren ontwikkelaars de mist in sturen. Controleer daarom altijd eerst het eindpunt en de parameters samen. Los die op, en in de meeste gevallen verdwijnt de gevreesde AADSTS900144 als sneeuw voor de zon.

Probleemoplossing aan de clientkant: opgeslagen inloggegevens wissen en apps resetten

Soms ligt het niet aan je code, maar aan de lokale machine die de authenticatiestroom verstoort. Gecachte referenties en oude cookies kunnen verlopen tokens bewaren of parametergegevens beschadigen, vooral in desktopapps zoals Microsoft Teams of Outlook. Gebruikers blijven dan de melding AADSTS900144 krijgen, ook nadat je de problemen aan de back-end hebt opgelost.

De eerste stap is het wissen van opgeslagen referenties. Gebruik in Windows het Referentiebeheer om gecachte tokens die aan je account gekoppeld zijn te verwijderen. In webapps kan het verwijderen van browsercookies en sitegegevens een schone herauthenticatie op gang brengen. Bij hardnekkige problemen, vooral in Microsoft Teams, kun je een lokale reset proberen: meld je overal af, sluit de app, verwijder de cachemappen en start daarna opnieuw op. Sommige gebruikers moeten hun Teams-accountprofiel via de apparaatinstellingen echt geforceerd verwijderen om er zeker van te zijn dat alle sporen weg zijn. Installeer Teams daarna opnieuw vanaf nul.

Als je anderen ondersteunt, geef dan een eenvoudige checklist: wis de referenties, sluit de app af, maak de cache leeg en meld je daarna weer aan. Zo beperk je de downtime en verwarring voor zakelijke gebruikers die alleen willen dat hun apps weer werken. IT-supportteams moeten altijd controleren of alle oude authenticatiegegevens weg zijn voordat ze verder graven, want achtergebleven rommel is een belangrijke oorzaak van hardnekkige AADSTS900144-fouten.

Voor wie worstelt met governance van Microsoft Teams of terugkerende authenticatieproblemen geldt: technische oplossingen alleen ‘lossen’ governance niet op. Wil je dieper ingaan op waarom governance nooit af is en hoe je het in de praktijk laat werken, bekijk dan deze gids over Teams-governance en de illusie van controle of bekijk dit playbook voor automatisering van de Teams-levenscyclus voor praktische strategieën.

Best practices om AADSTS900144 in zakelijke apps te voorkomen

Het voorkomen van de AADSTS900144-fout komt echt neer op discipline bij je OAuth-aanvragen en app-configuraties. Maak er een gewoonte van om alle verplichte parameters te valideren, vooral client_id en grant_type, voordat je aanvragen naar het Azure AD-tokenendpoint stuurt. Geautomatiseerde controles in je deploymentpipeline kunnen ontbrekende of foutief opgemaakte parameters vangen voordat ze in productie terechtkomen, en besparen je later veel tickets.

Gebruik de ontwikkelaarstools van Microsoft Entra ID om authenticatieaanvragen te simuleren en te zien wat Azure AD ziet. Dit helpt niet alleen ontbrekende parameters op te sporen, maar ook niet-overeenkomende endpoints of beleidsregels die geldige aanvragen in specifieke tenants kunnen blokkeren. Unittests met nagebootste Entra ID-endpoints verminderen verrassingen verder, omdat parameterproblemen al in de ontwikkeling naar boven komen en niet pas bij de livegang.

Voor organisaties met veel governance-eisen of meerdere ontwikkelteams is het zinvol je validatie te koppelen aan infrastructuur-als-code. Gebruik schemacontroles in ARM- of Bicep-deploymenttemplates om ervoor te zorgen dat alle verplichte OAuth-parameters bij de app-registratie worden opgenomen. Zo daalt het risico op configuratieafwijkingen en fouten naarmate apps evolueren.

Wil je een beveiligingsgerichte aanpak, let dan goed op OAuth-toestemmingsverleningen en het afdwingen van beleid. Aanvallers maken graag misbruik van losse toestemmingsinstellingen, dus beperk gebruikerstoestemming, vereis goedgekeurde uitgevers en dwing beheerdersworkflows af. Voor een degelijk overzicht van deze dreigingen en mitigerende maatregelen lees je deze uitleg over aanvallen op OAuth-toestemming in Entra ID. Als je governanceprocessen verfijnt, is het slim om automatisering, RBAC en Azure Policies in te zetten. Bekijk daarvoor deze strategiegids voor Azure-governance op enterpriseniveau voor ontwerpinzichten en concrete maatregelen.