A recent change in Webkit has broken authentication in ASP.Net Core 2 MVC apps that use the OpenIdConnect and Cookies middleware (like in all of our quickstarts and samples). In particular, after authenticating you might see:
- a redirect loop, where the application redirects to Auth0 and Auth0 redirects back to the application
- right after the authentication the application still thinks that the user is not authenticated until the page is refreshed.
The Cookies middleware uses a
samesite=laxpolicy for the session cookie (which is a good thing, security-wise). This cookie is set at the end of the authentication flow (on the callback processing handler).
WebKit’s interpretation of spec for the
SameSitepolicy causes Safari to block the session cookie set by the middleware on the immediate request after the authentication (usually the
ReturnUrl) if the authentication flow includes a
- A user typing credentials on a login form
- Auth0 returning the results to the application (because the OIDC middleware asks for the response to be POSTed back to the application).
A full flow looks like this:
- Visit site, access some protected resource (or trigger the login manually).
- Application redirects to the OIDC provider (Auth0) asking for an authentication.
- User completes all the authentication prompts.
- Auth0 sends back the result to the app by returning HTML to the browser that does a POST request.
- The OpenIdConnect middleware (at
/signin-auth0) validates the response, creates a login ticket. The Cookie middleware sets the identity cookie with a
- The middleware redirects to the protected resource (or to the home page).
- The middleware checks for the identity cookie, which is blocked by WebKit. Since it’s missing, return to step 2.
This issue is being discussed on WebKit’s bug tracker at https://bugs.webkit.org/show_bug.cgi?id=188165.
(Note that this problem is not exclusive to Auth0, it affects any OIDC flow).
See a workaround in the response below.