AADSTS900561: fout dat het eindpunt alleen POST-aanvragen accepteert

By Mirko Peters · 2026-04-22 · Updated 2026-07-28

Leer wat de fout AADSTS900561 (het eindpunt accepteert alleen POST) betekent, waarom die optreedt tijdens aanmelden bij Microsoft Entra, en hoe je het veilig oplost.

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

Kort antwoord: De fout AADSTS900561 (het eindpunt accepteert alleen POST) betekent dat een authenticatie-eindpunt van Microsoft Entra een aanvraag heeft ontvangen met een methode die niet wordt ondersteund. Controleer de aanmeldstroom van de applicatie, de afhandeling van de redirect en de exacte URL die wordt geopend, in plaats van steeds de identiteitsinstellingen van de hele tenant te wijzigen.

Ben je de fout AADSTS900561 tegengekomen tijdens het werken met Microsoft Entra ID of Azure Active Directory? Dit is de fout die zegt: ‘Endpoint only accepts POST requests’. In gewone taal betekent dit dat je app via een GET-aanvraag probeerde te communiceren met de authenticatieservice van Microsoft, terwijl de server een POST verwacht. Het is alsof je bij de achterdeur aanklopt terwijl je de voordeur had moeten gebruiken.

Deze fout komt vaak voor als je apps bouwt of integreert voor Microsoft 365, Azure of Power Platform. Meestal treedt hij op tijdens aanmeldstromen of wanneer je probeert een token op te halen bij het identiteitsplatform van Microsoft. Weten wat de fout AADSTS900561 veroorzaakt, is belangrijk, omdat die je direct wijst op de plek waar je authenticatieaanroepen niet aansluiten op de technische eisen van Microsoft. Hierna bekijken we precies waarom deze fout wordt gegeven en hoe hij samenhangt met een andere bekende foutcode, AADSTS90056.

AADSTS90056 en AADSTS900561: foutbeschrijving en achtergrond

Voordat je de fout AADSTS900561 gaat oplossen, is het handig om precies te weten waar je mee te maken hebt. Zowel AADSTS90056 als AADSTS900561 zijn foutcodes die Microsoft Entra ID (voorheen Azure AD) geeft wanneer er iets niet klopt in de manier waarop je app met de authenticatie-eindpunten communiceert. In het kort: AADSTS90056 wijst meestal op een onjuiste of ontbrekende authenticatieparameter, terwijl AADSTS900561 zich specifiek richt op HTTP-methodeproblemen, namelijk wanneer je GET gebruikt waar POST vereist is.

Microsoft Entra ID hanteert strikte protocolregels voor tokenuitwisselingen en aanmeldstromen, vaak gebaseerd op OAuth 2.0. Wanneer je app een token nodig heeft en het /token-eindpunt aanroept, verwacht Microsoft een POST-aanvraag. Dat is geen muggenzifterij: met een POST kun je gevoelige gegevens veilig in de body van de aanvraag meesturen in plaats van in de URL, wat het risico op lekken en onbedoeld loggen verkleint.

GET-aanvragen zijn daarentegen openboeken. Ze zetten je gegevens direct in de URL, zodat iedereen of elke proxy onderweg ze kan meelezen. Dat is een beveiligingsprobleem, zeker voor zakelijke diensten die identiteiten en gevoelige gegevens beheren. Daarom dwingt het identiteitsplatform van Microsoft POST af voor elke actie waarbij geheimen, codes of gebruikersgegevens worden uitgewisseld. Stuur je een GET, dan herkent het platform dat en grijpt het in met de fout AADSTS900561. Als je deze technische achtergrond kent, begrijp je niet alleen wat je fout deed, maar ook waarom die regel bestaat en waarom hij binnen de cloudservices van Microsoft niet onderhandelbaar is.

Kortom: als je een van deze codes ziet tijdens het authenticeren, doet je app een aanvraag die niet aan de regels voldoet. Met de achtergrond van beveiliging en een betrouwbare protocolstroom erachter, weet je veel beter wat je moet aanpassen en waarom dat belangrijk is in professionele app-omgevingen.

Veelvoorkomende oorzaken en oplossingen voor authenticatieproblemen met AADSTS900561

Als de fout AADSTS900561 optreedt, zit er vrijwel zeker een fout in de manier waarop je app het tokeneindpunt van Microsoft aanroept. Een van de belangrijkste oorzaken is een onjuist geconfigureerde app-registratie of een verkeerde redirect-URI in Azure AD. Als de geregistreerde redirect-URI niet overeenkomt met wat je app daadwerkelijk gebruikt, of er ontbreken vereiste onderdelen, dan kan er per ongeluk een GET-aanvraag worden verstuurd in plaats van de verwachte POST.

Een andere klassieke misser zit in de code van de aanmeldstroom zelf. Sommige ontwikkelaars gebruiken per ongeluk GET bij het aanroepen van het /token-eindpunt, vooral wanneer ze aanvragen handmatig opbouwen of de bibliotheek die ze gebruiken niet goed begrijpen. In OAuth 2.0 met Microsoft Entra moet de uiteindelijke tokenaanvraag altijd als POST worden verstuurd, nooit als GET. Als je workflow in deze stap een GET verstuurt, verschijnt de fout AADSTS900561 direct.

Hoe los je het dan op? Begin met het dubbelcheken van je redirect-URI's, zowel in je registratie in de Azure-portal als in de lokale configuratie van je app. Zorg dat ze exact overeenkomen, tot en met het protocol (http of https) en het pad. Gebruik je de MSAL- of ADAL-bibliotheken, controleer dan dat je niet op een oude versie zit en dat je geen code schrijft die het standaard POST-gedrag overschrijft. Gebruik je je eigen authenticatiecode, inspecteer dan je HTTP-aanroepen en bevestig dat het tokeneindpunt altijd met een POST-verzoek wordt aangeroepen.

Hulp nodig bij de code? Een snelle tip: gebruik je in JavaScript fetch of axios, zorg dan dat je aanroep naar /token er ongeveer zo uitziet: method: 'POST'. Zie je in je logs of in de browser de melding "endpoint only accepts post", dan is dat het sein om elke stap in je code tussen autorisatie en tokenuitwisseling na te lopen, zeker als je app schakelt tussen front-end- en back-endlogica. Voor een diepere duik in identiteitsgerelateerde risico's en praktische governance-oplossingen kun je deze aflevering over identiteit als controlevlak in Azure-beveiliging bekijken: this episode on identity as the control plane in Azure security.

Debuggen en best practices om AADSTS900561-fouten te voorkomen

Laten we beginnen met het opsporen van deze fout en ervoor zorgen dat hij je niet opnieuw achtervolgt. Draai je een single page app (SPA) met React, Vue of Angular? Open dan de ontwikkelaarstools van je browser. Ga naar het tabblad Netwerk, doorloop je loginflow en let goed op een GET-verzoek naar het /token-eindpunt. Zodra je dat ziet, heb je de boosdoener gevonden.

Soms ontstaat deze storing doordat je authenticatiebibliotheek niet goed is ingesteld. In MSAL.js bijvoorbeeld kan loginRedirect gebruiken waar je acquireTokenSilent bedoelde, of een verkeerde configuratie van de bibliotheek, waardoor er een GET in plaats van een POST wordt verstuurd. MSAL.js bijwerken naar de nieuwste versie en je initialisatie-instellingen nog eens nalopen kan je veel hoofdpijn besparen. Frameworks zijn kieskeurig, maar de documentatie van Microsoft is duidelijk: tokenverzoeken moeten een POST zijn.

Let ook op je Azure-logs. Controleer de aanmeldingslogboeken van Azure AD voor gedetailleerde verzoekgegevens. Je ziet welk eindpunt is aangeroepen, welke methode is gebruikt en eventuele signalen over afwijkingen in het protocol. Voor diepgaande diagnostiek kunnen tools als Fiddler het HTTP-verkeer regel voor regel uitsplitsen, en kan Application Insights de aanroepstack koppelen aan het precieze probleemgebied.

Voorkomen is beter dan genezen. Test je authenticatiestromen altijd eerst in dev en staging voordat je ze naar productie brengt. Zorg dat elk stuk code dat een autorisatiecode voor een token uitwisselt server-side draait, met een POST, precies zoals de OAuth 2.0-richtlijnen voorschrijven. Codes in de browser uitwisselen is een klassieke manier om AADSTS900561 uit te lokken en beveiligingslekken te openen.

Werk je in grotere Microsoft 365- of Azure-omgevingen, kijk dan kritisch naar je governance-aanpak. Entra ID vormt nu de basis voor veel kritieke toegang, dus een strak beleid en code die de best practices van Microsoft volgt, maakt het leven een stuk makkelijker. Voor meer over het ontwerpen van governance waarbij niets door de mazen glipt, is deze aflevering over de Azure enterprise governance-strategie zeker de moeite waard.

En als je app deel uitmaakt van het Power Platform, of gewoon connectors gebruikt, beheer dan je identiteiten en connectors zorgvuldig om architectuurafwijkingen en onverwachte machtigingsfouten te voorkomen. Praktische richtlijnen vind je in deze bron: Power Platform security and governance best practices.

Kort samengevat: ken je authenticatiestromen, valideer elk verzoek en houd je tools up-to-date. Als er toch een fout doorheen glipt, weet je precies waar je moet zoeken en hoe je hem definitief oplost.

Praktische checklist

• Bevestig de exacte gebruikersuitkomst en het getroffen bereik.
• Kies de smalste veilige configuratie of communicatiekeuze.
• Test de ervaring voordat je breed uitrolt.
• Leg eigenaarschap, vervolgacties en beoordelingsmomenten vast.

Veelgestelde vragen

Wat is de beste eerste stap?

Bepaal het gebruikersscenario en de specifieke uitkomst die je nodig hebt. Dat voorkomt onnodige wijzigingen en levert een duidelijkere, betrouwbaardere implementatie op.

🎧 Luister ook eens naar

• Identity Governance in Entra biedt de governancecontext rond identiteitsbeheer.
• Microsoft Entra Private Access – Simply Explained legt moderne identiteits- en toegangsarchitectuur uit.
• Privileged Identity Management (PIM) – Simply Explained voegt context over geprivilegieerde toegang toe voor Entra-beheerders.

Laatst beoordeeld: juli 2026.