Error "You May Have Pressed the Back Button" in Auth0
Last Updated:
Overview
End-users encounter an error when navigating the login flow incorrectly or using expired bookmarks. Resolving this issue requires configuring a Default Login Route at the tenant or application level to redirect users to a new authentication flow. A low percentage of users occasionally see an error page with the following message:
You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn't find your session. Try logging in again from the application and if the problem persists please contact the administrator.
Applies To
- Auth0
- Login flow
- Default Login Route
- Browser back navigation
Cause
There is no Default Login Route configured for the tenant, nor is there an Application Login URI configured for any applications.
This error can occur depending on certain end-user interactions with the login page or login flow. Here are some of the behaviors that may produce this error:
- Attempting to go to the login page through a bookmarked link.
- Pressing the back button mid-login flow.
- Refreshing the page during the login flow.
- Opening multiple login dialogs.
- Browser cookie settings block cookies.
When initiating an authentication flow with Auth0, the application makes a request to the authentication API /authorize endpoint. This authorized request contains all the context needed to initiate a login flow (tenant, application, scopes, etc.) and will redirect to the login page to enter the user credentials and perform a login request. For security reasons, each login request is associated with a previous call to the authorize endpoint via the state parameter.
Some of the actions listed above can prevent the login flow from being performed in the context of the correct authorization request and result in the "You may have pressed the back button..." error.
For example, bookmarking the Universal Login Page can cause the user to navigate to a login page corresponding to an old, expired authorization request. Because Auth0 does not have a current record matching this login attempt, the authentication flow will not work: Auth0 will block the request and return an error.
Solution
How is the Default Login Route configured?
Configuring a Default Login Route, either at the tenant or application level, will help redirect users to a new authentication flow whenever this error arises. The Default Login URL should point to an Application's endpoint, which can trigger a new authorize request to initiate the new flow.
These URIs can be configured in the Dashboard Application Settings or Tenant Advanced Settings or using the Management API.
Follow the steps or video below.
To configure an Application Login URI for an application:
- Go to Dashboard > Applications > Application Settings for the application.
- Scroll down to the Application URIs section.
- Enter the login URL in the Application Login URI field.
NOTE: This login URL should point to a route in the application that ends up redirecting to Auth0's /authorize endpoint, for example. https://mycompany.org/login. Also, note that it requires https and it cannot point to localhost, though it can include query parameters and a URI fragment.
To configure a Tenant Login URI
- Go to the Dashboard > Settings > Advanced.
- In the Login and Logout section, enter a login URL in the Tenant Login URI field.
What's the difference between an Application Login URI and a Tenant Login URI?
Both Default Login URIs address the same issue; however, sometimes Auth0 will not know the client ID (e.g., when hitting the /login endpoint without any parameters), so in those cases, the Tenant Login URL can be used as a fallback. If an application does not have an Application Login URI configured, the Tenant Login URI will also be used.
In cases where the client_id is known, the App's Default Login URI will take effect.
Another solution is to use the Allowed Callback URI when a custom URI scheme is used. This was the old way to redirect the native app. Now, HTTPS can be used instead. Refer to the documentation on Redirect Users for more details.
