Identity Server Login - A task was canceled

[musaDiplomat]

We are experiencing an inconsistent authentication state when a login flow is interrupted/cancelled (tab closed, navigation interrupted, refresh at the wrong time).
The result is a split authentication state:
IdentityServer believes the user is authenticated
SPA / BFF does not have a session cookie and returns 401
This leads to a redirect / login loop that the user cannot escape.

What happens (step by step)
User starts login on IdentityServer (username + password).
Credentials are validated using ASP.NET Core Identity:

SignInManager<AspNetUser> _signInManager;
await _signInManager.CheckPasswordSignInAsync(user, hashedPassword, false);

After business logic (partner resolution, additional checks, etc.), we sign in the user manually:

await HttpContext.SignInAsync(authenticatedUser);

During or immediately after this step, the login flow is interrupted (tab closed, navigation cancelled, etc.).
Resulting state after interruption
IdentityServer has an authentication cookie and treats the user as authenticated.
The SPA/BFF does NOT receive its session cookie.
Any call from the SPA to protected BFF endpoints (e.g. /bff/user) returns 401.
Because of the 401, the front-end assumes the user is logged out and displays a Login button.
What happens on the next login attempt
User clicks Login in the SPA.
The request reaches the IdentityServer login page.

We have logic similar to:

if (User?.Identity?.IsAuthenticated == true)
{
    // redirect back (already logged in)
}

Since IdentityServer still has the auth cookie from the interrupted attempt,
User.Identity.IsAuthenticated == true.

IdentityServer immediately redirects the user back to the SPA without establishing a valid BFF session.

This creates a loop:
SPA → BFF → 401 → show Login
Login → IdentityServer → “already authenticated” → redirect back
SPA → BFF → 401 again
The user is effectively stuck.

Key problem:
An interrupted login can leave the system in a half-authenticated state:
Server-side IdentityServer authentication cookie exists
Client-side (SPA/BFF) session does not
There is no automatic recovery path from this state.

Question
Is there a recommended way to prevent an authentication cookie from being issued or persisted if a login request is cancelled or aborted (tab closed, navigation interrupted, client disconnect, network loss)?

Specifically, is there any supported way to use a CancellationToken (or HttpContext.RequestAborted) to interrupt the login flow so that the user is not signed in on the IdentityServer side when the request is cancelled?

[wcabus]

Is your BFF part of your Duende IdentityServer solution by any chance? Or are these two sharing the same cookie?

When your BFF needs to authenticate the current user, it should start an OAuth + OpenID Connect flow to IdentityServer:

1. User is logged out from the SPA/BFF.
2. User clicks the Login button or link on the SPA/BFF side.
3. This triggers the /bff/login endpoint, which starts the OIDC flow by redirecting to IdentityServer.
4. During this flow, at the level of IdentityServer, the user is asked to enter their credentials if they don't have an active session. If they already have an active session, this step could be bypassed entirely (single sign-on).
5. User is authenticated at the IdentityServer level, the OIDC flow continues by redirecting back to the BFF.
6. The BFF now has confirmation that the user is authenticated, and can retrieve tokens from IdentityServer, set its own authentication cookie and let the SPA know that the user has authenticated.

The way you're describing the situation, leads me to believe that the OIDC flow isn't happening as its supposed to. Either because of custom code on the IdentityServer side of things, or because you're sharing cookies between the BFF and IdentityServer, which you shouldn't be doing.

[musaDiplomat]

That makes sense and confirms our understanding that once authentication/session cookies are written to the HTTP response, there is no way to undo this if the request is later aborted or cancelled.
The remaining issue in our case is that, after such an interrupted login, a retry from the BFF side does not successfully complete a new OIDC flow.

One additional clarification regarding our login page logic:
We intentionally added a check like the following for UX reasons:

if (User?.Identity?.IsAuthenticated == true)
{
    // redirect back (already logged in)
}

After a successful and fully completed login, once the OIDC flow has completed and the user has been redirected back to the BFF, this prevents the user from being taken back to the login page if they press the browser “Back” button.
This behavior is especially important on mobile devices, where accidental or frequent back navigation is common.
We are aware that removing this check entirely would effectively hide the issue, as the login flow would always continue and eventually re-establish the BFF session. However, that would come at the cost of a worse user experience, which we would strongly prefer to avoid.

The core challenge we are trying to solve is therefore:
preserve the good UX behavior for fully completed logins (IdentityServer + BFF session)
while still having a recovery path for the edge case where the login flow was interrupted after IdentityServer issued its authentication cookie but before the BFF session was established
Given that atomic login is not possible, is there a recommended pattern in a Duende BFF + IdentityServer setup to distinguish between:

• a fully completed login
• and a partially completed login (IdentityServer session only)
• without breaking the desired UX behavior?
  Any guidance on the recommended approach for handling this scenario would be greatly appreciated.

[wcabus]

In your custom redirect logic, when you detect that the user is already authenticated, are you redirecting back using the original redirect URL and potential additional state?

Our template UI shows an example of such a redirect: when the user is authenticated, provided that there is a valid login context, the user will be redirect back using the provided return URL, which completes the authentication flow before redirecting the user back to the client application.

[musaDiplomat]

Thanks, that’s very helpful.

Yes, in our implementation we currently short-circuit on User.Identity.IsAuthenticated == true and redirect the user directly to our partner base URL (SPA/BFF), instead of redirecting via the original returnUrl when a valid login/authorization context exists.

That works well for our “back button after a fully completed login” UX case, but it also explains why recovery fails after an interrupted login: IdentityServer has a session, but the BFF never gets the OIDC callback because we skip the authorize/returnUrl completion step.

We will review the template you posted and adjust our logic so that:

• if there is a valid authorization context (valid returnUrl), and the user is already authenticated, we redirect using the original returnUrl to complete the OIDC flow back to the BFF;
• only if there is NO valid authorization context (e.g., direct navigation to /login without returnUrl), we apply our UX shortcut and redirect to the partner base URL.

Does that match the recommended pattern?

[wcabus]

I'm inclined to answer "yes", but it could still depend on where this short-circuit is happening. It's definitely a good approach to first verify whether there is a valid authorization context before using the return URL value, but I'm still confused why you had to add this short-circuit logic.

When the authorize endpoint redirects the user back to the login UI, it most likely had a good reason to do so.

[musaDiplomat]

Thanks for the clarification,

after reviewing this with your feedback in mind, we realized that our original approach to handling the “already authenticated” case was indeed too aggressive. We were short-circuiting the login flow based solely on User.Identity.IsAuthenticated, without first validating whether there was an active authorization context that still needed to be completed.

Some of the guidance in this thread helped us spot that mistake. We’ve now adjusted the logic so that:

• we first check for a valid authorization context;
• only if such a context exists do we redirect using the returnUrl to properly complete the OIDC flow back to the BFF;
• only when there is no authorization context (e.g. direct navigation to the login page or back navigation after a completed login) do we apply the UX shortcut and redirect the user to the partner/SPA base URL.

With this change, the interrupted-login edge case is handled correctly, and the redirect loop is resolved, while still preserving the UX behavior we were aiming for.
Thanks for taking the time to respond your pointers definitely helped us correct our handling of this scenario.