Error "400 Bad Request - Request Header Or Cookie Too Large" in ASP.NET MVC Application with AzureAD Authentication

Question

Error "400 Bad Request - Request Header Or Cookie Too Large" in ASP.NET MVC Application with AzureAD Authentication

Lydia 0

Hello,

We are experiencing an issue with our ASP.NET MVC application that involves multiple iframes. Each iframe embeds the same application, which may be hosted on different domains. Authentication within each iframe is performed using AzureAD.

When the iframes are loaded, some of them encounter the error "400 Bad Request - Request Header Or Cookie Too Large" during requests to the path "/signin-oidc". This issue appears to be related to the cookies .AspNetCore.OpenIdConnect.Nonce and .AspNetCore.Correlation.AzureADOpenID, which are sent multiple times in the request headers.

I have attached an image to demonstrate this behavior.

Could you please provide an explanation for why this issue occurs and suggest potential solutions to handle this situation?

Thank you for your assistance. AspNetCoreCookies

Anonymous

Hello @Lydia,

Thanks for posting your question in the Microsoft Q&A forum.

This happens when the identity tokens gets too large. If the token contains too many claims, it might cause the cookie too large, and will show the 400 error.

To handle the 404 errors for /admin/host/ping in your ASP.NET MVC application hosted in Azure App Services, while reducing unnecessary logs in Application Insights, consider implementing the following solution:

Create a custom route for the /admin/host/ping endpoint:

routes.MapRoute( name: "AzurePing", url: "admin/host/ping", defaults: new { controller = "AzurePing", action = "Index" } );

Implement a controller to handle this route:

public class AzurePingController : Controller { public

Modify your Application Insights configuration to filter out these specific requests:

TelemetryConfiguration.Active.TelemetryProcessorChainBuilder
    .Use((next) => new FilteringTelemetryProcessor(next))
    .Build();

public class FilteringTelemetryProcessor : ITelemetryProcessor
{
    private ITelemetryProcessor Next { get; set; }

    public FilteringTelemetryProcessor(ITelemetryProcessor next)
    {
        this.Next = next;
    }

    public void Process(ITelemetry item)
    {
        if (!OkToSend(item)) { return; }

        this.Next.Process(item);
    }

    private bool OkToSend(ITelemetry item)
    {
        var request = item as RequestTelemetry;
        if (request != null && 
            request.Url.AbsolutePath.Equals("/admin/host/ping", StringComparison.OrdinalIgnoreCase))
        {
            return false;
        }
        return true;
    }
}

Thanks, Chaithra

Anonymous

2025-02-06T09:47:06.34+00:00

Hello @Lydia,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thanks,
Chaithra E
Lydia 0 Reputation points

2025-02-06T16:04:20.02+00:00

Hello @Anonymous ,

Thank you for your response. The code you provided above does not apply to our situation, as we are attempting to address a 400 error that occurs when the cookie size is too large with AzureAD. Could you please provide any other suggestions related to our situation?
Anonymous

2025-02-12T06:17:07.23+00:00

Hello @Lydia,

To resolve the issue, try clearing your cookies or using a private browsing window.

Alternatively, if the HTTP request is hosted on IIS with Kerberos authentication and the user belongs to many Active Directory groups, the server may send a "400 - Request Too Long" error, as mentioned here. In this case, it is recommended to remove the user from some of the Active Directory groups.

I hope this helps!
SrideviM 5,710 Reputation points Microsoft External Staff Moderator

2025-02-12T16:11:52.0566667+00:00

Hello @Lydia,

Just following up to see if Chaithra’s suggestions helped. If the issue is still happening, you might try using session storage or a distributed cache for authentication state instead of cookies to reduce header size. Minimizing unnecessary claims in the token can also keep the cookies smaller.
SrideviM 5,710 Reputation points Microsoft External Staff Moderator

2025-02-14T04:43:53.7033333+00:00

Hello @Lydia,

Following up to see if the provided suggestions are helpful or not. And, if you have any further query do let us know.
Lydia 0 Reputation points

2025-02-17T14:28:59.03+00:00

Hello @Anonymous ,

We attempted to reduce the number of Active Directory groups the user is a member of, but this did not resolve our issue. Please let me know if you have other suggestions. Thank you!
SrideviM 5,710 Reputation points Microsoft External Staff Moderator

2025-02-18T02:19:26.6766667+00:00

Hello @Lydia,

Reducing AD group membership alone won’t fix the issue, as it’s mainly caused by large authentication cookies. A better approach is to use a Session Store in CookieAuthenticationOptions, which keeps authentication data in memory instead of cookies, reducing header size and avoiding server limits. You can start with an in-memory implementation and later switch to a distributed cache if needed, though that would make the app stateful. Refer this article

Another useful step is splitting cookies by subdomain and site paths, so they’re only sent when necessary. If possible, keep static resources on a separate subdomain to avoid sending cookies with every request. Also, trimming unnecessary claims from authentication tokens and using LocalStorage for client-side data can help.

Hope this helps!

2 answers

Your answer

Anonymous

2025-02-04T16:58:23.91+00:00

Hello @Lydia,

Thanks for posting your question in the Microsoft Q&A forum.

This happens when the identity tokens gets too large. If the token contains too many claims, it might cause the cookie too large, and will show the 400 error.

To handle the 404 errors for /admin/host/ping in your ASP.NET MVC application hosted in Azure App Services, while reducing unnecessary logs in Application Insights, consider implementing the following solution:

Create a custom route for the /admin/host/ping endpoint:

routes.MapRoute( name: "AzurePing", url: "admin/host/ping", defaults: new { controller = "AzurePing", action = "Index" } );

Implement a controller to handle this route:

public class AzurePingController : Controller { public

Modify your Application Insights configuration to filter out these specific requests:

TelemetryConfiguration.Active.TelemetryProcessorChainBuilder .Use((next) => new FilteringTelemetryProcessor(next)) .Build(); public class FilteringTelemetryProcessor : ITelemetryProcessor { private ITelemetryProcessor Next { get; set; } public FilteringTelemetryProcessor(ITelemetryProcessor next) { this.Next = next; } public void Process(ITelemetry item) { if (!OkToSend(item)) { return; } this.Next.Process(item); } private bool OkToSend(ITelemetry item) { var request = item as RequestTelemetry; if (request != null && request.Url.AbsolutePath.Equals("/admin/host/ping", StringComparison.OrdinalIgnoreCase)) { return false; } return true; } }

Thanks, Chaithra
Anonymous

2025-02-06T09:47:06.34+00:00

Hello @Lydia,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thanks,
Chaithra E
Lydia 0 Reputation points

2025-02-06T16:04:20.02+00:00

Hello @Anonymous ,

Thank you for your response. The code you provided above does not apply to our situation, as we are attempting to address a 400 error that occurs when the cookie size is too large with AzureAD. Could you please provide any other suggestions related to our situation?
Anonymous

2025-02-12T06:17:07.23+00:00

Hello @Lydia,

To resolve the issue, try clearing your cookies or using a private browsing window.

Alternatively, if the HTTP request is hosted on IIS with Kerberos authentication and the user belongs to many Active Directory groups, the server may send a "400 - Request Too Long" error, as mentioned here. In this case, it is recommended to remove the user from some of the Active Directory groups.

I hope this helps!
SrideviM 5,710 Reputation points Microsoft External Staff Moderator

2025-02-12T16:11:52.0566667+00:00

Hello @Lydia,

Just following up to see if Chaithra’s suggestions helped. If the issue is still happening, you might try using session storage or a distributed cache for authentication state instead of cookies to reduce header size. Minimizing unnecessary claims in the token can also keep the cookies smaller.
SrideviM 5,710 Reputation points Microsoft External Staff Moderator

2025-02-14T04:43:53.7033333+00:00

Hello @Lydia,

Following up to see if the provided suggestions are helpful or not. And, if you have any further query do let us know.
Lydia 0 Reputation points

2025-02-17T14:28:59.03+00:00

Hello @Anonymous ,

We attempted to reduce the number of Active Directory groups the user is a member of, but this did not resolve our issue. Please let me know if you have other suggestions. Thank you!
SrideviM 5,710 Reputation points Microsoft External Staff Moderator

2025-02-18T02:19:26.6766667+00:00

Hello @Lydia,

Reducing AD group membership alone won’t fix the issue, as it’s mainly caused by large authentication cookies. A better approach is to use a Session Store in CookieAuthenticationOptions, which keeps authentication data in memory instead of cookies, reducing header size and avoiding server limits. You can start with an in-memory implementation and later switch to a distributed cache if needed, though that would make the app stateful. Refer this article

Another useful step is splitting cookies by subdomain and site paths, so they’re only sent when necessary. If possible, keep static resources on a separate subdomain to avoid sending cookies with every request. Also, trimming unnecessary claims from authentication tokens and using LocalStorage for client-side data can help.

Hope this helps!

Answer 1

Bruce (SqlWork.com) 78,086 Volunteer Moderator

This is typically caused by the user having too many role claims that makes the token too large to stored in a cookie. You are probably mapping all roles, you will need to refine the mapping.

Lydia 0 Reputation points

2025-02-06T15:52:29.0666667+00:00

Hello Bruce, thank you for your response. We have already attempted to include only the necessary roles in the token, but we are still encountering the same error. Do you have any suggestions?

Answer 2

We have already attempted to include only the necessary roles in the token, but we are still encountering the same error. Do you have any suggestions?

If I understand correctly, you've verified the problem is with the cookie size. After trimming claims to only the necessary roles the authentication cookie is still too large. If this is true and not a bug in the logic then you can't store the claims in a cookie. Store the claim in somewhere else that the application can get to like a database or cache.

Share via

Error "400 Bad Request - Request Header Or Cookie Too Large" in ASP.NET MVC Application with AzureAD Authentication

2 answers

Your answer