How to resolve infinite loop issue in Azure AD authentication in Asp.Net MVC application

Question

How to resolve infinite loop issue in Azure AD authentication in Asp.Net MVC application

Arpit Tandon 0

We have an Asp.Net MVC application running on v4.6.1. We are implementing SSO authentication using Azure AD. We are using Microsoft.Owin.Security.OpenIdConnect library for cookie based authentication.

Below is our auth configuration -

public void ConfigureAuth(IAppBuilder app)
{
    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {

        AuthenticationType = "Cookies",
        CookieSecure = CookieSecureOption.Always,
        CookieSameSite = Microsoft.Owin.SameSiteMode.None,
        CookieManager = new SystemWebChunkingCookieManager()
    });

    app.UseOpenIdConnectAuthentication(
        new OpenIdConnectAuthenticationOptions
        {
            ClientId = ClientId,
            Authority = Authority,
            ClientSecret = OidcClientSecret,
            PostLogoutRedirectUri = PostLogoutRedirectUri,
            RedirectUri = PostLogoutRedirectUri,
            Scope = OpenIdConnectScope.OpenIdProfile + " roles",
            ResponseType = OpenIdConnectResponseType.Code,                    
            TokenValidationParameters = new TokenValidationParameters
            {
                ValidateIssuer = false // Set to true in production if you know the exact issuer
            }
        });
}

Problem -

We are facing infinite loop issue during authentication where /authorize endpoint call and localhost redirect calls are going in loop. Eventually, with multiple nonce cookies being sent, the request becomes too large and fails with 400 Bad Request or we get the error saying "we couldn't sign you in".

Solutions we have tried -

Using https for local development so that nonce cookie with secure attribute can be set

Using SystemWebChunkingCookieManager() as CookieManager

We are still stuck with the problem and need suggestions for resolution.

1 answer

Your answer

Answer 1

Raymond Huynh (WICLOUD CORPORATION) 2,215 Microsoft External Staff

Hello Arpit Tandon, this redirect loop with Azure AD + OWIN is typically caused by a callback/redirect mismatch, cookie settings, or an auth type mismatch. Here are my recommendations:

Make the redirect exact
- Set RedirectUri = https://<host>:<port>/signin-oidc and CallbackPath = "/signin-oidc".
- Register that exact URI (scheme/host/port/path) in Entra ID; don’t reuse PostLogoutRedirectUri.
Order and auth types
- Call app.SetDefaultSignInAsAuthenticationType("Cookies").
- Use UseCookieAuthentication(...) before UseOpenIdConnectAuthentication(...).
- In OIDC: SignInAsAuthenticationType = "Cookies" (must match cookie AuthenticationType).
Cookies/SameSite/nonce
- CookieSecure = Always, CookieSameSite = None, CookieManager = new SystemWebChunkingCookieManager().
- Prevents nonce/correlation cookie loops and large headers.
HTTPS only
- Run on HTTPS even locally; mixed HTTP/HTTPS drops secure cookies and retriggers auth.
Update OWIN/Katana (optional helper)
- Update Microsoft.Owin.* packages to latest (older versions had nonce/correlation bugs).
- Optional legacy helper: app.UseKentorOwinCookieSaver() before cookies.
- References: https://github.com/Sustainsys/owin-cookie-saver

Minimal working config:

app.SetDefaultSignInAsAuthenticationType("Cookies");
 
app.UseCookieAuthentication(new CookieAuthenticationOptions {
    AuthenticationType = "Cookies",
    CookieSecure = CookieSecureOption.Always,
    CookieSameSite = Microsoft.Owin.SameSiteMode.None,
    CookieManager = new SystemWebChunkingCookieManager()
});
 
// optional (legacy): app.UseKentorOwinCookieSaver();
 
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions {
    ClientId = ClientId,
    Authority = Authority,
    ClientSecret = OidcClientSecret,
    RedirectUri = "https://localhost:44300/signin-oidc",
    PostLogoutRedirectUri = "https://localhost:44300/",
    CallbackPath = new PathString("/signin-oidc"),
    ResponseType = OpenIdConnectResponseType.Code,
    SignInAsAuthenticationType = "Cookies",
    TokenValidationParameters = new TokenValidationParameters { ValidateIssuer = false } // set true in production
});

If a loop persists, confirm X-Forwarded-Proto=https behind proxies and use a shared machine key across instances. Hope this solves your problem.

Arpit Tandon 0 Reputation points

2025-09-26T09:52:26.57+00:00

Hi @Raymond Huynh , thanks for taking out time to help.

Regarding RedirectUri, we have https://localhost:44300/ setup as RedirectUri and we are using same Uri for both RedirectUri and PostLogoutRedirectUri. Can using same uri as both redirects cause issue?

Regarding X-Forwarded-Proto=https, I don't think it is required for local development.
Raymond Huynh (WICLOUD CORPORATION) 2,215 Reputation points Microsoft External Staff

2025-09-26T10:33:40.94+00:00
Hello Arpit Tandon ,

Yes, using the same URI for both redirects causes trouble if it’s your site root.

RedirectUri must be the exact OIDC callback (typically .../signin-oidc) that matches the middleware’s CallbackPath. Pointing it to the root breaks nonce/correlation validation and triggers the loop.

Keep PostLogoutRedirectUri as your landing page (often the root). Don’t reuse it for RedirectUri.

This aligns with known OWIN/Entra patterns and community reports on redirect loops when the callback isn’t exact.
Raymond Huynh (WICLOUD CORPORATION) 2,215 Reputation points Microsoft External Staff

2025-10-01T10:50:41.4566667+00:00

Hi Arpit Tandon ,
Have you fixed this issue?
Arpit Tandon 0 Reputation points

2025-10-06T13:09:20.79+00:00

Hi @Raymond Huynh Haven't checked using exact OIDC callback yet.

If I change my redirectUri to .../signin-oidc, can I change my default controller's action also to be called on .../signin-oidc route rather than .../ so that after authentication when redirect happens to .../signin-oidc, it directly calls my action method to return mvc view ?
Raymond Huynh (WICLOUD CORPORATION) 2,215 Reputation points Microsoft External Staff

2025-10-07T09:17:21.7066667+00:00
Hi Arpit Tandon ,

You're correct to change the RedirectUri to /signin-oidc. This is the standard callback path that the OIDC middleware handles internally to process the authentication response.

Don't create a controller action for /signin-oidc. The middleware automatically intercepts this path to handle tokens and create the session cookie. After processing, it will redirect to your default route (/).

Just ensure:

Your RedirectUri in code is set to https://your-domain/signin-oidc

The exact same URI is registered in your Azure AD app

Your default route (/) points to your desired MVC action

Arpit Tandon 0

After changing redirect uri to https://localhost:44300/signin-oidc, my configuration is as follow:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = "Cookies",
    CookieSecure = CookieSecureOption.Always,
    CookieSameSite = Microsoft.Owin.SameSiteMode.None,
    CookieManager = new SystemWebChunkingCookieManager()
});
app.UseOpenIdConnectAuthentication(
    new OpenIdConnectAuthenticationOptions
    {
        ClientId = ClientId,
        Authority = Authority,
        ClientSecret = OidcClientSecret,
        PostLogoutRedirectUri = "https://localhost:44300/",
        RedirectUri = "https://localhost:44300/signin-oidc",
        Scope = OpenIdConnectScope.OpenIdProfile + " roles",
        ResponseType = OpenIdConnectResponseType.Code,
        CallbackPath = new PathString("/signin-oidc"),
        SignInAsAuthenticationType = "Cookies",
        TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = false // Set to true in production if you know the exact issuer
        }
    });

Now, I am getting following issue -

I think middleware is not redirecting to "/" route.

Raymond Huynh (WICLOUD CORPORATION) 2,215 Reputation points Microsoft External Staff

2025-10-13T04:28:53.4133333+00:00

Hi Arpit Tandon ,

The /signin-oidc path shouldn’t be an actual controller route, it’s handled internally by the OWIN middleware. Seeing a 404 means the OIDC middleware isn’t getting a chance to intercept that request.

Please make sure your UseOpenIdConnectAuthentication(...) call is inside the Startup.Auth.cs (or Configuration(IAppBuilder app)) method and placed before app.UseMvc() or app.UseWebApi(). If MVC runs first, it’ll treat /signin-oidc like a normal route and return 404.

Once the middleware order is correct, the /signin-oidc request should be processed automatically and the page won’t appear in the browser .
Arpit Tandon 0 Reputation points

2025-10-13T14:01:20.17+00:00

UseOpenIdConnectAuthentication(...) call is placed correctly inside Startup.Auth.cs

I don't have any call to app.UseMvc() or app.UseWebApi(), rather I have the configuration (i.e. Area registration, Route registration and Autofac module registrations) done through Application_Start() method of Global.asax.cs

Authentication configuration is done in Startup.Auth.cs and it is being called from partial class Startup having OwinStartup attribute.Regarding sequence of execution - Configuration in Global.asax.cs is running before authentication configuration in Startup. Is there a way to change this sequence?
Harry Vo (WICLOUD CORPORATION) 3,355 Reputation points Microsoft External Staff Moderator

2025-10-24T04:30:30.99+00:00
Hello @Arpit Tandon ,

The infinite loop is likely not about your route registration sequence, but rather how OWIN middleware interacts with the authentication flow. In your Startup.Auth.cs, after your OIDC configuration, add:

app.UseOpenIdConnectAuthentication(oidcOptions); app.UseStageMarker(PipelineStage.Authenticate); // Add this line

Share via

How to resolve infinite loop issue in Azure AD authentication in Asp.Net MVC application

1 answer

Your answer