Understanding the AADSTS900561 Endpoint Only Accepts POST Error

Ever run into the AADSTS900561 error while working with Microsoft Entra ID or Azure Active Directory? This is the one that says, “Endpoint only accepts POST requests.” What it means, in plain language, is your app tried to talk to Microsoft’s authentication service using a GET request, but the server expects a POST. It’s like knocking on the back door when you should’ve used the front.

This error shows up often when you’re building or integrating apps for Microsoft 365, Azure, or Power Platform. It usually hits during sign-in flows or when trying to get a token from Microsoft’s identity platform. Knowing what triggers the AADSTS900561 error is key because it points you straight to where your authentication calls aren’t matching Microsoft’s technical requirements. Next up, let’s break down exactly why this gets thrown and how it’s tied to another familiar error code, AADSTS90056.

AADSTS90056 and AADSTS900561 Error Description and Background

Before you dive into fixing the AADSTS900561 headache, it helps to know exactly what you’re dealing with. Both AADSTS90056 and AADSTS900561 are error codes thrown by Microsoft Entra ID (formerly Azure AD) when something’s off in the way your app talks to the authentication endpoints. The shorthand is: AADSTS90056 usually points to a bad or missing authentication parameter, while AADSTS900561 is laser-focused on HTTP method issues—specifically, when you use GET where POST is required.

Microsoft Entra ID uses strict protocol rules for token exchanges and authentication flows, often built around OAuth 2.0. When your app needs to get a token by hitting the /token endpoint, Microsoft expects you to send a POST request. That’s not just them being picky—POST requests allow you to send sensitive data securely in the request body, not in the URL, reducing risk of leaks and accidental logging.

GET requests, on the other hand, are open books. They stick your details right there in the URL for anyone or any proxy along the way to see. That’s a security problem, especially for enterprise services managing identities and sensitive data. So Microsoft’s identity platform enforces POST for any action that involves exchanging secrets, codes, or user info. If you send a GET, the platform sniffs it out and slams on the brakes with the AADSTS900561 error. Knowing this technical background helps you understand not only what you did wrong, but why that rule exists—and why it’s non-negotiable across Microsoft cloud services.

In sum, if you’re seeing either of these codes while authenticating, your app’s making a request that doesn’t play by the rules. With the context of security and reliable protocol flow behind these error codes, you’ll have a much clearer sense of what to fix and why it matters in professional app environments.

Common Causes and Solutions for AADSTS900561 Authentication Issues

If AADSTS900561 is showing up, you can almost bet there’s a misstep in how your app is reaching out to Microsoft’s token endpoint. One of the top culprits? A misconfigured application registration or a bad redirect URI in Azure AD. If your registered redirect URI doesn’t match what your app actually uses—or it’s missing required details—you might accidentally trigger a GET request instead of the expected POST.

Another classic mix-up is in the way your authentication flow itself is coded. Some devs accidentally use a GET when calling the /token endpoint, especially if they’re trying to craft requests manually or misunderstood the library they’re using. In OAuth 2.0 with Microsoft Entra, the final token acquisition should always be sent as POST, never GET. If your workflow sends a GET at this step, the AADSTS900561 error will pop right up.

So, how do you fix it? Start by double-checking your redirect URIs in both your Azure portal registration and your app’s local configuration. Make sure they’re a perfect match, right down to the protocol (http or https) and path. If you’re using MSAL or ADAL libraries, make sure you’re not on some old version or writing code that overrides their default POST behavior. If you’re using your own custom authentication code, inspect your HTTP calls to confirm the token endpoint is always hit with a POST request.

Need some code help? Here’s a quick tip: in JavaScript, using fetch or axios, make sure your call to /token looks something like method: 'POST'. If you’re seeing “endpoint only accepts post” in your logs or browser, that’s your cue to check every step your code takes between authorization and token exchange—especially if your app switches between front-end and back-end logic. For a deeper dive on identity-driven risks and real-world governance fixes, check out this episode on identity as the control plane in Azure security.

Debugging and Best Practices to Prevent AADSTS900561 Errors

Let’s talk about tracking this error down and making sure it doesn’t haunt you again. If you’re running a single page app (SPA) using React, Vue, or Angular, bring up your browser’s developer tools. Hit the Network tab, try your login flow, and keep an eagle eye out for a GET request hitting the /token endpoint. The moment you see it, you’ve found your culprit.

Sometimes, this glitch happens because your authentication library isn’t set up right. In MSAL.js, for instance, using loginRedirect where you meant acquireTokenSilent or misconfiguring the library can cause it to fire off a GET instead of a POST. Updating MSAL.js to the latest version and double-checking your initialization settings can save endless headaches. Frameworks are picky, but Microsoft’s docs are pretty clear about the need for POST on token requests.

Don’t sleep on your Azure logs, either. Check Azure AD sign-in logs for detailed request traces. You’ll see which endpoint was called, which method was used, and any flags about protocol mismatches. If you want deep diagnostics, tools like Fiddler can break down HTTP traffic line by line, and Application Insights can map the call stack right to the trouble spot.

Prevention is better than “clean up on aisle five.” Always test your authentication flows in dev and staging before unleashing them to production. Make sure every bit of code that exchanges an authorization code for a token is running server-side, with POST, just like the OAuth 2.0 guidebook says. Exchanging codes in the browser is a classic way to get AADSTS900561 and open up security holes.

If you work in bigger Microsoft 365 or Azure environments, take a look at your governance approach. Entra ID now underpins a lot of critical access, so keeping your policies tight and your code following Microsoft’s best practices makes life a lot easier. For info on designing governance that won’t let stuff slip through the cracks, this Azure enterprise governance strategy episode is well worth a look.

And if your app is part of the Power Platform—or even just uses connectors—manage your identities and connectors carefully to avoid architectural drift and surprise permission errors. You’ll find actionable guidance in this resource: Power Platform security and governance best practices.

Bottom line? Know your authentication flows, validate every request, and keep your tools updated. If an error does sneak through, you’ll know exactly where to look and how to stamp it out for good.