A customer of ours raised an issue about being unable to login. After investigating, we found some strange behavior from Auth0 that we were not expecting. Would appreciate any insight you could give us on this situation and how to handle it.
Scenario:
We use a customized Classic Universal Login loaded at https://MY_CUSTOM_DOMAIN.com/login. I attempt to navigate to the login page but supply all junk data in the query parameters:
Expected Behavior
Either Auth0 shows an error page or else redirects me back to my default login URL as described here: Configure Default Login Routes
Actual Behavior
Auth0 loads the login page normally (200 response). Attempting to login from the page returns a 404 error from the /usernamepassword/login route.
I’ve tried to reproduce the behaviour you are experiencing and described but had no success. After appending /login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X to my custom domain, I just get redirected to my default login route.
You’ve mentioned that Auth0 loads the login page normally. I find that very confusing since using junk parameters won’t allow Auth0 to know which login page to actually serve. You really need to provide some of those parameters. When you say the login page was loaded, do you mean your Classic Universal Login page? From my point of view, that might not be possible with junk parameters.
In addition to what I’ve said, the expected flow would be to call /authorize and not /login. This is documented on our Authentication API documentation.
Since all this don’t make much sense to me, I would suggest you provide a HAR file while reproducing the entire flow so I can take a deeper look at what’s going on there. Please, do not forget to remove any credentials, secrets or active/valid Access Tokens that might be found inside the HAR file. You can also DM me the HAR file if you are concerned about security/privacy.
Hi @Ale, I will work on generating a HAR file and provide it soon. In the meantime, I can try to clarify some of the points you raised and provide some additional details.
One potentially important bit I learned since posting – while we do have an Application Login URI set with our default login route, we do not have a tenant-wide route set in the Tenant Login URI field.
To your question: Yes, I mean that the Classic Universal Login Page (which we have customized) is being loaded. I get a 200 response where the response body contains the same custom HTML that I can see when I got to the Branding -> Universal Login -> Login tab in the Tenant Dashboard.
We are initiating our login flow using /authorized in the normal flow. Navigating directly to /login is definitely non-standard behavior. I only found out about this while reproducing an error raised by a user. The actual error scenario was more complicated, but the root issue is what I mentioned here.
The real in-the-wild scenario that brought this to my attention:
We have a main production tenant, and also a second tenant used as a testing sandbox for clients integrating into our app
A user loaded the production app, which would make a call to /authorize then load the /login page
The user had intended to go to the sandbox application and could not login to the production app
Realizing their mistake, they manually changed the MY_CUSTOM_DOMAIN part of the URL to MY_CUSTOM_DOMAIN_SANDBOX without changing any of the parameters
The sandbox login page loaded but they still could not login or change their password, and the issue was escalated to me
@Ale I have sent you a DM with the HAR file. It was generated starting from a blank incognito window and navigating directly to https://MY_CUSTOM_DOMAIN.com/login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X by pasting the URL.
I understand now what you said with “the page loaded normally”.
This is basically the issue here. When using incorrect parameters, Auth0 does not know which application configuration/settings should be used. Since you don’t have any tenant-wide default route set up, there’s no possible redirection. The solution would be to implement a tenant-wide default login route then.
Now, since we don’t show any error for this scenario, it’s true that the end result can be confusing for this specific scenario (users that don’t set up a tenant-wide default login route). I think this use case is not considered an error by design, but I personally can see room for improvement. I’d suggest sending your feedback to https://auth0.com/feedback to get this logged properly just in case Product agrees with you and decide to improve our solution based on your feedback.
Thanks for the help @Ale . I think we have a good solution for now then, just by setting the tenant-wide route.
I can make a Feedback post to get this considered for improvement as well.
However, I do still have one quibble with your point “I think this use case is not considered an error by design”. If that is the truly case, then I think there is a disconnect between the app design and the documentation that would still constitute an issue rather than an improvement.
Specifically, when reading the Configure Default Login Routes I saw this passage which contributed to my confusion and seems to run counter to your statement about the intended design:
Sometimes users bookmark the login page, and when they navigate to the bookmarked /login URL, the transaction record is no longer there and Auth0 cannot continue with the login flow. In that case, Auth0 will redirect to the default client URL if configured, or the tenant level URL if not. If no default login URL is set, Auth0 will render an error page.
What you said made sense to me so I’ve been doing some testing and these are the outcomes when using noTenant Login URI:
New Universal Login:
1.1 . Calling /authorize?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X returns an error page as expected.
1.2 . Caling /login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X returns an error page as expected.
Classic Universal Login:
2.1 . Calling /authorize?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=X returns an error page as expected.
2.2 . Calling /login?state=X&client=X&protocol=X&connection=X&audience=X&redirect_uri=X&scope=X&response_type=X&response_mode=X&nonce=X&code_challenge=X&code_challenge_method=X&auth0Client=Xshows a blank page.
There’s clearly a mismatch when comparing the New Universal Login experience to the Classic Universal Login experience. Also, it’s true that what we say in our documentation is not what happens when calling the /login endpoint under the Classic UL experience.
I will report this to our Engineering team so they can hopefully add this to their backlog. Thank you again for reporting it!!!