CODEWITHSUNDEEP
asp.net-mvccookiesazure-active-directoryowinopenid-connect
NiAu
NiAu

Reputation: 627

ASP OpenID Connect: Bad Request, request too long

For a website which uses OpenID Connect to authenticate to Azure, I got sometimes the message 'Bad request - Request too long. the size of the request headers is too long'. The issue now occurs on Google Chrome MF and Edge. After deleting the cookies, the site will work for one session. On restart of the browser the problem returns. I'm running version 4.0.0 of the OpenID Connect package.

The issue is known and caused by the nonce cookies which are created by openid connect. When it shows the error, at that moment, more than 20 of those cookies exist in the browser (Chrome, Firefox and Edge). I tried different things, but still no solution.

EDIT

When downgrading the OpenIDConnect package to version 3.0.0, the first time I open the browser (after setting published code in IIS) login is succeeded and it forwards to the correct page. When closing and reopening the browser (when user was still logged in) an infinite loop starts at login because the User.Identity.IsAuthenticated is always false even after a successful login.

Upvotes: 1

Views: 6220

Answers (2)

loganpixel
loganpixel

Reputation: 87

Solved Chrome "OpenID Connect: Bad Request, request too long" on our system. But now Firefox is looping.. /smh

I had the same error but my solution ended up being different. I would authenticate via Azure AD connect successfully. Login.microsoft would redirect back to my app. The app would then bounce back to login.microsoft and it would loop there until it ended in the Bad Request Took To Long error. I then noticed I had around 39 cookies for OpenID.connect for the app. If I deleted them, it would loop on reload. If I deleted them and deleted the login.microsoft cookies, I was back to the start and login successful but loop after login. Checking here and researching further, I discovered the issue was in the AccountController.cs file. It seems that after the login page, it was going to the root of the server, not the root of the application. This server has a few applications on it. The default setting was RedirectUri = "/" which goes to the root of the server. The app doesnt exist there so it would loop back. After the loop back login.microsoft would give another okay cookie and send back, lol. I just needed to change the RedirectUri = "/" to RedirectUri = "/serverfolderpath" and it worked!!

AccountController.cs

     if (!Request.IsAuthenticated)
        {
            HttpContext.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/subFolderHere" },
                OpenIdConnectAuthenticationDefaults.AuthenticationType);
        }

I discovered this by checking into the clue "Check Azure Authentication in web application" as the issue seemed to me that the app was thinking authentication was false. The truth was it never got back to the app.

Check Azure Authentication in Web Application

Upvotes: 3

Marilee Turscak - MSFT
Marilee Turscak - MSFT

Reputation: 7728

Odd that deleting your cookies and trying in a new browser did not work!

Try adding the following to your web.config:

<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxQueryString="32768"/>
    </requestFiltering>
  </security>
</system.webServer>

See:

http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits

You may have to add the following in your web.config as well:

<httpRuntime maxQueryStringLength="32768" maxUrlLength="65536"/>

Of course these numbers are just examples and you don't have to use these exact values in these settings.

Also, a solution to the infinite looping situation: http://erlend.oftedal.no/blog/?blogid=55

Upvotes: 1

Related Questions