Duende.BFF Identity Server LogIn glitch /bff/login -> /signin-oidc (SPA + Razor login page, OIDC + Cookies)

[musaDiplomat]

Hello,

I’m experiencing an issue with the login flow in my setup and would like to describe it thoroughly so the community can help.

🔸 Project architecture

• SPA frontend (React/Next) calling the bff/login endpoint.
• Duende BFF Gateway (YARP) – runs on the same DNS as the SPA, configured with cookie authentication and oidc challenge scheme.
• IdentityServer (Duende) – external IdP that serves the login page (Razor Page).
• Authentication: Cookie-based (server-side sessions).
• Session rule: Only one active session per user at a time (previous sessions are revoked on new login).

🔸 When the problem occurs

• On a normal internet connection, the login flow mostly works, but occasionally glitches:
• In most cases the user logs in successfully.
• Sometimes the glitch occurs, leaving the user stuck on the login page or with a failed login flow.
• On a slow internet connection (Chrome dev tools → throttling 3G), the login always fails:
• The redirect to /connect/authorize/callback is triggered, but the cookie/session does not validate correctly.
• The user is never able to complete login.
• Easiest way to reproduce: open Chrome, throttle network to 3G, then try login → login becomes impossible.

🔸 Configuration (simplified) Gateway (BFF):

builder.Services
    .AddAuthentication(options =>
    {
        options.DefaultScheme = "cookie";
        options.DefaultChallengeScheme = "oidc";
        options.DefaultSignOutScheme = "oidc";
    })
    .AddCookie("cookie", options =>
    {
        options.Cookie.SameSite = SameSiteMode.Lax;
        options.Cookie.HttpOnly = true;
    })
    .AddOpenIdConnect("oidc", options =>
    {
        options.Authority = builder.Configuration["InteractiveServiceSettings:AuthorityUrl"];
        options.ClientId = "13";
        options.ClientSecret = "xxx";
        options.ResponseType = "code";
        options.SaveTokens = true;
        options.GetClaimsFromUserInfoEndpoint = true;
        options.Scope.Add("openid");
        options.Scope.Add("profile");
        options.Scope.Add("offline_access");
        options.Scope.Add("api");
    });

🔸 Behavior

On slow networks, some requests appear to execute out of order or overlap.

In Chrome DevTools, I can see the final call to /Account/Login?ReturnUrl=... sometimes happens after the authorize/callback should have completed.

Result:

• On normal networks → login usually succeeds, but sometimes glitches.
• On slow networks → login always fails, user cannot proceed past login page.

🔹 Question for the community

• Has anyone experienced a similar issue with Duende BFF + IdentityServer login flow on slow or unstable networks?
• Is there a way to enforce that login requests are processed sequentially (wait for authorize/callback to finish before other calls)?
• Are there any known configuration pitfalls or workarounds for this scenario?
• Any advice or experience would be greatly appreciated 🙏

[toni-diplomat-tech]

Has anyone experienced a similar issue with Duende BFF + IdentityServer login flow on slow or unstable networks?
Yeah 😂

[maartenba]

Hi @musaDiplomat - would you have logs/exceptions that are observed? Also are you using PAR (Pushed Authorization Requests)? What version(s) of .NET, BFF and IdentityServer are you using? This would help in diagnosing the issue.

[musaDiplomat]

Hi @maartenba,
Here are the details :

• .NET version: .NET 8.0
• Duende.BFF: 3.0.0
• Duende.BFF.Yarp: 3.0.0
• Duende.IdentityServer: 7.2.4
• RequirePushedAuthorization: currently set to false in the database Client table

At the moment, there are no exceptions or warnings in the logs that indicate a potential bug or failure — both on the BFF and IdentityServer sides.
However, when inspecting the Network tab (Chrome) during login with throttled 3G speed, we can see that the /Account/Login request sometimes completes after the /connect/authorize/callback request, which likely causes the login flow to fail.

Here is the network screenshot of the success scenario:

[maartenba]

Thanks! Would you bae able to share BFF and IdentityServer logs as well to see if anything sticks out?

Regarding "Session rule: Only one active session per user at a time (previous sessions are revoked on new login)" - in your implementation do you have any logging? I am wondering if this by accident also removes the newly created session based due to timing.

[musaDiplomat]

Hi,
We’ve identified and resolved the issue.
The root cause was the UserSsoLifetime setting for our client (in the Clients table) being set to 0.
What UserSsoLifetime does
UserSsoLifetime limits how long an existing user session can be reused for Single Sign-On (SSO) with a given client.
NULL (or not set): no client-specific SSO limit; the user’s existing session can be reused as long as it’s valid.
A positive number (seconds): reuse is allowed up to that duration since the user’s original authentication.
0: reuse is never allowed; the user must re-authenticate for that client every time.

Why it “glitched”
With UserSsoLifetime = 0, IdentityServer consistently prompted for login again at the authorize step (“showing login”), which looked like a glitch/loop to the user.

[maartenba]

That's a good find, thanks for confirming @musaDiplomat !

[Erwinvandervalk]

Also, when you say 'glitch', what do you mean? Are you seeing an error? Or is the user redirected back to identity server's login page?

[musaDiplomat]

The user is redirected to login page and the inputs are cleard.
https://github.com/user-attachments/assets/d65da5fc-a178-425a-8bb1-b0f5aaa10b17