This post was most recently updated on February 9th, 2024.
8 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?
Description
I ran into this when logging into SharePoint. That was surprising – I’d never quite seen this before:
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: https://docs.microsoft.com/azure/active-directory/develop/active-directory-protocols-oauth-code. 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.
Source: https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-aadsts-error-codes
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!
To understand the background of this error, let’s first look at what the authentication API does and why it needs different types of requests.
Background
The authentication API is a service that verifies the identity and permissions of users and applications that want to access Microsoft Entra resources, such as email, files, calendars, etc. The authentication API uses a protocol called OAuth 2.0, which is a standard for secure authorization. OAuth 2.0 defines several ways of obtaining an access token, which is a string that represents the user’s or application’s credentials and scopes.
Explaining these different ways to obtain access tokens is a bit beyond the scope of this article, but generally speaking there will be a few different requests to the authentication API of Microsoft Entra, performed either by the backend or by the browser. Some of these requests will be of type GET, and some are POST.
One typical case (authorization code flow) is that the GET request is used to redirect the user to the authorization endpoint and obtain the authorization code. The POST request is used to send the authorization code to the token endpoint and obtain the access token. The reason why the authentication API requires different types of requests is to ensure the security and integrity of the data. The GET request is visible in the browser’s address bar and can be intercepted by malicious parties, so it should only contain data that is not sensitive, such as the client ID and the scope. The POST request is hidden from the browser and can be encrypted, so it can contain data that is sensitive, such as the client secret and the authorization code.
Now, what happens if the web application sends a GET request to the token endpoint instead of a POST request? This is one case where the AADSTS900056 error occurs. The authentication API will refuse to serve the GET request and return an error message that says: “The request method must be POST when requesting an access token”. This is because the authentication API does not want to expose the sensitive data in the URL, which could compromise the security of the user and the application. The authentication API expects the web application to follow the OAuth 2.0 protocol and use the appropriate type of request for each endpoint.
There are quite a few different reasons that might cause the issue. Some such examples are:
- The library or the middleware is outdated or buggy and does not follow the OAuth 2.0 protocol correctly. For example, it may use the wrong URL for the token endpoint or the wrong parameter for the response type. (If you’re the developer, you can fix this)
- The library or the middleware is misconfigured and does not pass the correct parameters to the authentication API. For example, it may use the wrong client ID, the wrong client secret, the wrong redirect URI, or the wrong scope. (If you’re the developer, you can fix this)
- You’re calling the Microsoft Entra Authentication API (usually login.microsoftonline.com) with HTTP instead of HTTPS. (If you’re the developer, you can fix this)
- Microsoft has been changing how Entra Authentication API works and it’s running into unexpected errors. (You can’t fix this)
- Your browser is mixing up the cookies to use and is unable to successfully complete the authentication flow (this is the one case where a normal user can try to fix the issue!)
In any of these scenarios, the result is (or at least CAN BE) that the web application sends a GET request to the token endpoint instead of a POST request, and the authentication API returns the AADSTS900056 error.
Solutions
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
- (OPTION 1) Verify the issue is not caused by your browser
If this error gets thrown at you when you’re authenticating against a website yourself, 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! - Open cookie settings
Navigate to this link in Google Chrome: chrome://settings/content/cookies
- 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!
- 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. - 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? - (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:
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)
{
// ...
services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options =>
{
Configuration.Bind("AzureAd", options);
System.Console.WriteLine(options);
});
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
// ...
app.UseAuthentication();
// ...
}
}
}
Logging in against http://login.microsoftonline.com doesn’t work. Change it to https://login.microsoftonline.com 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!
References
- Microsoft’s explanation of most AADSTS -errors:
- https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-aadsts-error-codes
- It’s not very thorough, but should give you pointers in a lot of cases.
I also have quite a few articles about fixing different AADSTS errors, you might find it helpful: https://www.koskila.net/?s=AADSTS
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
- How to stop Surface Headphones from autoplaying audio when you place them on the desk? - December 10, 2024
- “Phone Link” permanently disabled and Windows claiming “Some of these settings are managed by your organization”? (Probably) an easy fix! - December 3, 2024
- Refreshing DefaultAzureCredential in Visual Studio - November 26, 2024
