System.Exception: An error was encountered while handling the remote login. ---> System.Exception: Correlation failed.
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.HandleRequestAsync()
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.MigrationsEndPointMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
Hey there @johann, do you have any additional details that may occur within the logs when the issue is triggered? Also can you DM me your tenant name when you get a chance. Thanks in advance!
The “Correlation failed” message is the .Net OIDC SDK’s login CSRF attack protection at work. The OAuth2 protocol, on which OIDC is based, asks client applications to use the state parameter to ensure that the authentication response received in the application matches a request done by the same user.
The .Net OIDC stack stores a correlation id in a cookie and includes the same value in the state parameter. When receiving the authentication response (which contains the same state used in the request) it checks that the correlation id in the state can be found in a cookie, thus ensuring that the browser from where the authentication response is delivered also initiated the request.
The “Sign in” feature essentially generates an authentication response that the application didn’t ask for (and it can’t provide a state), so every client application that correctly implements the OAuth2 protocol will fail the correlation check. This check was less common a few years ago, but as implementors start using the appropriate security measures the “Sign in as” flow becomes essentially impossible to use.
@eduardo_ramires Are you using the “Sign in as user …” feature (i.e. impersonation)? If so, it’s not going to work with ASP.Net, period.
If you are just getting the “Correlation failed” exception without impersonation, what browser are you testing this on? Have you tried other browsers? Are you testing this on localhost? With HTTP or HTTPS?
A .HAR file (Generate and Analyze HAR Files) would go a long way in understanding if the correlation cookie is being generated and sent back on the callback request.
Good question, i have not tested with other browsers, and yeah i am just getting the Correlation Failed, sorry to use this post for my situation hehehe
I am getting this issue both in the production and locally, but i am not using “localhost” i am using HOSTs entries.
Both HTTP and HTTPS give the same issue.
One thing that i saw fixing this for some weird reason is triggering the customization on the hosted pages on and off, then it suddenly pass thro to my secured area.
When i log off, it immediatelly give the same issue again in the next login attempt so, it’s not a fix, it’s just something that happens.
I don’t know what the .HAR file is, i will look into it and see what happens
