Azure Active Directory, the advanced logo

Resolving error AADSTS90056

This post was most recently updated on January 10th, 2020.

Reading Time: 4 minutes.

This post details my very simple solution to an extremely unnecessary and kind of a simple error 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 is as such:

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

I’ve seen another version of the same error, where the endpoint announces it only accepts POST requests, not even OPTIONS. And definitely not GET :)

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

Description

I ran into this when logging into SharePoint. That was surprising – I’d never seen quite 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 does AADSTS90056 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.

https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-aadsts-error-codes

Funnily, 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 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 just you 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 you can try to fix this!

Solution

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, you can access the setting like this in Google Chrome:

  1. Navigate to this link in Google Chrome: chrome://settings/content/cookies
  2. Unselect “Block third-party cookies” (see below)

If you are, it apparently messes up the authentication loop and redirects you to an address that doesn’t expect a GET-request (but rather a POST-request from the 3rd party which you were supposed to authenticate against).

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; }
 
        // This method gets called by the runtime. Use this method to add services to the container.
        // For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=398940
        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 I’m aware of. Hope it was helpful!

References

mm

Leave a Reply

avatar
5000
  Subscribe  
Notify of