Azure Active Directory, the advanced logo

How to resolve AADSTS90056 – “The endpoint only accepts POST requests. Received a GET request.”

This post was most recently updated on March 8th, 2023.

5 min read.

This post details my very simple solution to an extremely unnecessary and kind-of simple error that I encountered when logging into SharePoint. However, you could run into the same error after configuring Azure Active Directory authentication to a custom web application.

The error message comes in at least 2 variants. These are shown below:

AADSTS90056: This endpoint only accepts POST, OPTIONS requests. Received a GET request.

The other one I’ve seen doesn’t even mention OPTIONS, just POST:

AADSTS900561: The endpoint only accepts POST requests. Received a GET request.

Ah – Microsoft is throwing their classic error “subcodes” around again. AADSTS90056 variants might come with a 1 or 2 added to the end (AADSTS900561 I’ve seen multiple times, AADSTS900562 not yet – but it’ll come!)

This adds a bit of flair to the errors, and possibly makes googling easier. But this time, the solution(s) are the same (if you’re encountering this in a browser on a Microsoft web property, that is!)

So, what’s wrong, and how to fix this?


I ran into this when logging into SharePoint. That was surprising – I’d never quite seen this before: throwing an error: AADSTS90056: This endpoint only accepts POST, OPTIONS requests. Received a GET request. throwing an error: AADSTS90056: This endpoint only accepts POST, OPTIONS requests. Received a GET request.

The error seemed very unrelated to what I was doing, so I was surprised. I originally ran into it when just clicking a link that pointed to SharePoint but wrote it off as a one-time thing. I decided to dig into the error a bit more only after running into it again, this time when configuring Azure AD authentication to my web application.

What do AADSTS90056 (and AADSTS900561) errors mean?

This is another one of a long list of error codes returned by Azure AD Security Token Service. The way Microsoft explains this error is as follows:

BadResourceRequest – To redeem the code for an access token, the app should send a POST request to the /token endpoint. Also, prior to this, you should provide an authorization code and send it in the POST request to the /token endpoint.

Refer to this article for an overview of OAuth 2.0 authorization code flow: Direct the user to the /authorize endpoint, which will return an authorization_code. By posting a request to the /token endpoint, the user gets the access token.

Log in the Azure portal, and check App registrations > Endpoints to confirm that the two endpoints were configured correctly.


Funnily enough, most of the time this information doesn’t help you. Why? Well…

While the direct cause for this error is the authentication API refusing to serve GET-type requests at all (instead of offering to serve POST or OPTIONS requests – first of which is usually used for authenticating and the latter for checking whether an API has the capabilities you expect it to have), the actual cause is a bit more complex. It’s not typically you just deciding to use the wrong type of a request – most of the time the developer isn’t really crafting the requests himself, after all. Typically it’s either the library/middleware misbehaving or being misconfigured and hence calling an unexpected address, or the API encountering something it doesn’t know how to deal with and redirecting the user to surprising locations.

Sound complicated and opaque? Well, it IS at least pretty opaque. But there’s a couple of simple things that you can try in order to fix this!


So, I’ve found 2 solutions to this issue:

First of all, you can’t be blocking 3rd party cookies. Some browsers might do this by default, or perhaps it is set up by your Active Directory administrators – but in case you have control over this yourself, I’m showing below how you can fix that.

Secondly, if you’re building some cool custom application and the login is failing for that (and fixing your browser didn’t help), there’s another tip on how to verify you’re configuring your authentication properly.

Time needed: 15 minutes

How to fix AADSTS90056 in your browser or custom application

  1. (OPTION 1) Verify the issue is not caused by your browser

    If this error gets thrown at you when you’re authenticating against a service, verify that it happens in all browsers! If it doesn’t, you probably have an issue with your browser.

    For Chrome, I’m detailing how to fix this in the next few steps!

  2. Open cookie settings

    Navigate to this link in Google Chrome: chrome://settings/content/cookies

  3. Allow third-party cookies

    Unselect “Block third-party cookies” – this is needed for some authentication scenarios. If it doesn’t help, remember to undo this change!

    How to block 3rd party cookies in Google Chrome (or most Chromium-based browsers)?

  4. Clear your cookies

    If this still didn’t help, clear cookies like shown here: How to log in to Microsoft’s websites (MSDN forums, Azure Portal, SharePoint Online) when you get a “Bad Request” error?

    It’s a more thorough guide than what I can fit here.

  5. Fix the authentication in the app or custom code

    In case the above fixes didn’t apply or help, you might need to verify that the authentication in whichever custom component or application you’re using or developing is configured properly.

    If you have access to the configuration, this link should help you.
    How to fix authentication in your .NET app?

  6. (OPTION 2) How to fix authentication in your .NET app?

    If none of the fixes above helped, let’s take a look at your app configuration (in case you do have access to it!)

    The second thing to try – both for Azure AD authentication and, weirdly enough, SharePoint Online, is to verify the URL of the endpoint is proper. The link in SharePoint that redirected me, redirected me to a http -address instead of https. I don’t know what was up with that – an SPFx webpart on the page having authentication misconfigured, or something like that, perhaps.

    However, I run into the issue myself a bit later on – I configured my .NET Core web application to use AAD authentication middleware. My appsettings.json file looked something like this:
    Misconfigured Azure Active Directory authentication in a .NET web app - you can't use http instead of https for the authentication endpoint (!

    And this was fed into the configuration simply like this:

    namespace Contoso.Web

    public class Startup

    public Startup(IConfiguration configuration)
    Configuration = configuration;

    public IConfiguration Configuration { get; } public void ConfigureServices(IServiceCollection services)
    // ...
    .AddAzureAD(options =>
    Configuration.Bind("AzureAd", options);

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    // ...
    // ...

    Logging in against doesn’t work. Change it to instead.

    If even this doesn’t help you, or if you’re developing the authentication middleware yourself, verify that you haven’t messed up a redirect or a reply-url somewhere!

Okay – so these were the ways to fix AADSTS90056 (and its close variant, AADSTS900561) I’m aware of. Hope it was helpful!

And yes, I DID somehow really end up trying to authenticate against HTTP instead of HTTPS. Lucky Microsoft doesn’t allow that, but they COULD throw some exception that’s a bit more transparent… :)

If you end up running into the issue and find another way to fix it, please share it with the community! And of course, any other feedback, in the comments -section below!


4.8 5 votes
Article Rating
Notify of

most voted
newest oldest
Inline Feedbacks
View all comments