Logins failing for some external tenants in our Blazor/ASP Identity app

Question

Our company develops a Blazor app which uses the ASP Identity framework authentication middleware. Identity framework helps us support SSO so that users can sign in to our app with Microsoft 365 or Google work accounts. It was working fine for the year or so that we've been using Blazor as well as the 3 years we had it on Razor pages before that. As far as we can tell our setup is very basic and straightforward.

Within the past few months, two of our clients have been struggling to log in to our app. They are redirected to Microsoft sign-in, and then their browser 404's when they are redirected to our app. It's the default IIS 404 page, not one returned by our code or even Blazor itself. Application Insights isn't even logging the attempt to reach the page.

I must stress that this started happening relatively recently given the total timeframe our app has been set up this way and it's limited to just 2 clients. Everyone else seems to be able to log in just fine. I can't think of a way these problem clients would get redirected to a different callback endpoint. I don't even know how I could set it up to do such a thing on purpose.

All clients get redirected to the same login callback after logging into their identity provider. We do not have separate configurations for separate clients.

Answer 1

Colin Wade Thank you for the detailed clarification. That helps narrow this down significantly.

Even though OpenID Connect is not something you configure directly, ASP.NET Core Identity uses OIDC internally when Challenge() is invoked with the Microsoft provider. The /signin-microsoft endpoint you’re seeing is the internal callback endpoint registered by the authentication middleware, and its responsibility is to process the authorization response (code, state, session_state), establish the authentication session, and then issue a 302 redirect to your configured ExternalLoginCallback.

Given that:

The request reaches /signin-microsoft

The response is a default IIS 404

Application Insights does not log the request

The failure occurs before your callback controller is reached

The only observable difference is larger code and state values in failing cases

This strongly indicates that the request is being rejected at the IIS or infrastructure layer before the ASP.NET Core middleware pipeline executes, rather than failing inside Identity or your application logic.

A common cause of this behavior is IIS request filtering limits, particularly:

Maximum query string length

Maximum URL length

When these limits are exceeded, IIS returns a 404 immediately and does not forward the request to the application, which matches the behavior you’re observing exactly. This also explains why:

The issue affects only certain external tenants

It began recently

Successful and failing requests differ only in parameter size

Some tenants (for example, those with Conditional Access, MFA, or additional claims) can generate larger authorization payloads, increasing the size of the code and state parameters.

Recommended next steps

Review IIS logs for the failing requests to confirm rejection at the web server level.

Verify or temporarily increase request limits in IIS, for example:

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

1. If applicable, also check any reverse proxy, WAF, or load balancer in front of IIS for similar request size limits.