Identityserver4: Opening multiple sign in tabs and AntiForgeryToken cookie=strict

[AndersAbel]

If a user initiates logins from a client in different tabs, only the last opened login form works.

This is a separate issue than #2484 which relates to a form loaded before login is invalidated after login.

Steps to reproduce:

1. Start login sequence from a client and show IdSrv4 login form page.
2. Open another tab, start login sequence from the same or another client and show IdSrv4 login form page.
3. Go back to tab from step 1 and submit login details => fails due to anti forgery token validation failure.

The reason for this is that when the form in step 1 is rendered an AntiForgeryToken cookie is set with SameSite=strict. In step two, the MVC anti forgery protection finds out there is a need for an anti forgery token in the form created and checks for an existing cookie to reuse. But none is present in the second request, due to the SameSite=Strict setting and the login sequence being initiated from another host. So a new AntiforgeryToken cookie is set with. When the form in the first tab is submitted, the tokens mismatch and validation fails.

Note that if instead of starting the login sequence from a client in step 2, /account/login is accessed directly the same cookie is reused and everything works.

Is this desired behaviour? Or would it make sense to lower the AntiForgeryToken to SameSite=lax, which would prevent this situation?

[brockallen]

Yea, I think this is a side effect of Microsoft having set the AntiForgery cookie to strict. We'll have to relax it explicitly. // Of mild interest, @tratcher?

[AndersAbel]

I'm not sure if this is a setting that should be in IdSrv automatically. I think it should make more sense to put it in the list of things that are recommended to do in Startup when using MVC server side forms for the login screens.

[Tratcher]

Yea, I think this is a side effect of Microsoft having set the AntiForgery cookie to strict. We'll have to relax it explicitly. // Of mild interest, @Tratcher?

@blowdart

[blowdart]

We've said that we don't support you trying to login in two different tabs at the same time before. It's a weird user story :)

[brockallen]

We've said that we don't support you trying to login in two different tabs at the same time before. It's a weird user story :)

FWIW, this would be true of any page/form sequence, not just a login form.

[AndersAbel]

We've said that we don't support you trying to login in two different tabs at the same time before. It's a weird user story :)

FWIW, this would be true of any page/form sequence, not just a login form.

If you login with the form in one tab, I'm perfectly fine with the login form in another tab being blocked by AntiForgeryToken (due to user id mismatch). In fact I think it is a feature to block in that case.

The user story that caused this question is a little different though:

1. User logs in to SPA.
2. User opens same SPA in another tab.
3. User clicks logout in tab 2, causes a federated sign-out.
4. Tab 2 logs out, hits SPA start URL, is redirected to IdSrv login, setting a new AntiforgeryToken cookie.
5. Tab 1 detects log out on IdSrv (session handling), logs out, hits SPA start URL, is redirected to IdSrv login, sets a new AntiForgeryToken cookie. All while tab 2 is still active.
6. User tries to login again in tab 2, the one user had active all the time and it fails due to mismatch on AntiForgeryToken.

I think it is a reasonable user story. Have two tabs open. Logout in one of them and when login form is displayed log in as another user. But if you have several tabs open, you have to find out which of them was the last one to load the login form and then use that tab to log in... because all the other ones are nonworking.

[hugoqribeiro]

You could detect the sign-out between tabs, alert the user and "force" him to refresh the page.
I think that GitHub does something like that...
Off course this is just a workaround...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Questions are community supported only and the authors/maintainers may or may not have time to reply. If you or your company would like commercial support, please see here for more information.

[k30v1n]

I am facing this issue as well, and I couldn't find an easy way to implement this user story.

But we can at least catch this exception using MVC filters as this PR enabled (https://github.com/aspnet/Mvc/pull/8604), and redirect the user for a proper error page. Maybe saying that s/he tried to submit the same information twice, or something like that.

It's basically this:

public class RedirectAntiforgeryValidationFailedResultFilter : IAsyncAlwaysRunResultFilter
{
    public Task OnResultExecutionAsync(ResultExecutingContext context, ResultExecutionDelegate next)
    {
        if (context.Result is AntiforgeryValidationFailedResult result)
        {
            context.Result = new RedirectResult("http://example.com/antiforgery-redirect");
        }

        return next();
    }
}

[brockallen]

Closing because It's a weird user story

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.