Identity Server 4, ASP.NET Core Identity and registration return url

Question

I have an Identity Server application with ASP.NET Core Identity interface to manage login, registration, ecc.

I have some MVC applications that rely on the Identity Server to authenticate.

Everything is working correctly: when I try to access a protected page, I'm redirected to the login page and, after login, I'm redirected back to the protected page that is now accessible.

The only problem is that the returnUrl passed to the login page is something like

/connect/authorize/callback?client_id=myClientId&redirect_uri=https://localhost:44309/signin-oidc&response_type=code&scope=openid profile email offline_access&code_challenge=yyfbWuF...&x-client-SKU=ID_NETSTANDARD2_0&x-client-ver=5.5.0.0

If I add this url to my registration confirm email link, it will work only if the link is opened in the same browser where I started the authentication request.

If the confirm email link is opened in another browser it will confirm the account and login correctly, but, when redirected to the client, it will cast an exception:

Exception: Correlation failed.

Unknown location
Exception: An error was encountered while handling the remote login.

Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler<TOptions>.HandleRequestAsync()

This is because, i guess, the new browser doesn't have the cookies generated during the authentication attempt in the other browser.

So my question is: is there any way to get the original protected page url, when redirected to the login page, so I can use that in my confirm email link?

It should be enough, because, once the account is confirmed I would be redirected back to my protected page that should fire a new authentication request to the login page, but, being already logged in, it would be a silent authentication.

Answer 1

"This is because, i guess, the new browser doesn't have the cookies generated during the authentication attempt in the other browser."

This is also my understanding.

One approach to this issue is to handle the error gracefully on the client side. If this type of error occurs (correlation failed), we know something is not right with the authentication and we redirect to the login page on the client side. (Perhaps, an unfriendly is trying to gain access, so redirect to the login page.)

In terms of a user confirming their email on a different browser, I think that is reasonable to redirect to a login page and have them login. They register, confirm their email and then are asked to log in to the application if it is a different browser.

Let me know if you worked something else out!