Feature: Redirect to Error Page if user has disabled cookies
Description:
If a user disabled cookies in his browser and tries to login with auth0, auth0 is not able to execute the login and redirects to the application login url instead of the error page.
As we understand it (from reading the documentation), there are two different scenarios regarding errors in the Auth0 Login Page:
Error a) the link to the auth0 login page has been bookmarked, the user wants to use this link but the state parameter has been expired. Therefor, auth0 redirects to the Application Login URI and asks the Application to restart the Login.
Please note, that according to the documentation (Application Settings) the Application Login URI “needs to point to a route in your application that redirects to your tenant’s /authorize endpoint”.
Error b) some parameter has been configured wrong (like clientId, callback url, etc.). In this case, auth0 redirects to the defined Error Page and passes a few query parameters to the error page to describe exactly what error happened.
In this case, it’s our responsibility, to understand the query params and show the user the error messages on our own website.
But now, if a user disabled their cookies, we run into the exact same error handling as in Error A. As you might realise, this now causes an endless loop. Auth0 explicitly asks the application for an endpoint, that starts the authorization flow – and redirects the user to this endpoint.
In our opinion, this is not a feature request but a bug. Or broken by design, whatever you want to call it.
We currently have multiple environments and tenants, so we can share some details under which circumstances the issues happens (all scenarios share the same prerequisite that the cookies have been disabled):
scenario 1: tenant defined a custom error page (https://example.com/error) and the application defined an application login uri (https://example.com/login):
As soon as the user tries to open the /authorize endpoint from auth0, they get redirected to https://example.com/login?iss=Auth0_Issuer.
scenario 2: tenant did not define a custom error page and the application did not define an application login uri
As soon as the user tries to open the /authorize endpoint from auth0, they get a generic error page shown with an invalid_request error message
scenario 3: tenant defined a custom error page (https://example.com/error) and the application did not define an application login uri
As son as the user tries to open the /authorize endpoint from auth0, they get redirected to the https://example.com/error?client_id=&connection=&lang=de-DE%2Cde%3Bq%3D0.9&error=invalid_request&error_description=You%20may%20have%20pressed%20the%20back%20button%2C%20refreshed%20during%20login%2C%20opened%20too%20many%20login%20dialogs%2C%20or%20there%20is%20some%20issue%20with%20cookies%2C%20since%20we%20couldn%27t%20find%20your%20session.%20Try%20logging%20in%20again%20from%20the%20application%20and%20if%20the%20problem%20persists%20please%20contact%20the%20administrator.&tracking=....
Use-case: We have multiple native mobile apps and our users disable the cookies in their mobile safari browser. This leads to the situation where user tap on the login button in the app, the app opens the webview for auth0 and auth0 redirects to our login page. This goes on and on and on. Users are complaining to us and we did not know for a while why auth0 redirected them to the login page WITHOUT any hint.
It would be great, if this could be fixed and a correct error handling implemented. It simply makes no sense to ask our application to start the login flow again after auth0 redirect the user to us because of disabled cookies. The cookies will not be enabled after you redirected the user to us. So why not simply using the error-handling for all other errors that can’t be resolved by simply restarting the login flow?