400 on /authorize should result in error being set and/or loading being false

[tfmark]

Describe the problem you'd like to have solved

In the screenshot below I have loaded our landing page, auth0 is silently trying to hit <auth0_tenant>/authorize and is getting a 400 back. isAuthenticated is false, isLoading is true, error is undefined, so I should just sit and wait for auth0 to do something...

Once the internal auth0 timeout eventually triggers (60s? 120s? I forget), isLoading is set to false / and error is set to Timeout.

I can then happily show my user a login page, but the user has probably gotten bored and closed the tab by that point.

Describe the ideal solution

User should not be sat at our loading screen waiting for auth0's timeout to trigger

Alternatives and current work-arounds

Don't show user a loading page whilst auth0 is loading...

Screenshot from Network tab

[adamjmcgrath]

Hi @tfmark - thanks for raising this.

Unfortunately, there's no way for the browser window to know what the status (or the content) of the /authorize page is. All the SDK can do is listen for an event from the other window and timeout if it doesn't get one.

I can then happily show my user a login page, but the user has probably gotten bored and closed the tab by that point.

You should only get this when the client is incorrectly configured, so this should only happen during development.

[tfmark]

Thanks for the swift reply @adamjmcgrath - is it possible to tweak the timeout (to e.g. 5 seconds)? We are seeing clients sat on the Loading page until the timeout is hit - it's not just something that is happening in dev, so would be nice to only have them sat for a few seconds rather than a minute+.

[adamjmcgrath]

You can use authorizeTimeoutInSeconds

But you shouldn't be getting 400s with a correctly configured client - your tenant logs should tell you what the issue is and you should be able to resolve it in code.

[tfmark]

Aha, am seeing Failed Silent Auth (The specified redirect_uri 'https://.tradefeedr.com' does not have a registered origin.). I guess that is related to having useRefreshTokens={true} so gonna deploy that change and check in the morning once my token has expired.

Failing that I'll also set a timeout to 5 seconds 👍 - will report back tomorrow and hopefully close out this ticket.

[adamjmcgrath]

By default, the SDK falls back to the web_message flow when the refresh token fails (like when there isn't a refresh token because you've turned refresh tokens on but there are active sessions without refresh tokens).

You either need to:

• set "Allowed Web Origin" here https://auth0.com/docs/get-started/applications/set-up-cors#configure-cross-origin-authentication so the fallback works
• disable the web_message fallback by setting useRefreshTokensFallback: false

[Alvaro948]

Hi @adamjmcgrath ,

Thanks for your anwser, had the same problem and setting useRefreshTokensFallback: false fixed the issue.

In my particular case, this was a capacitor / angular application with refresh tokens enabled.

https://community.auth0.com/t/auth0-app-id-doesnt-link-with-the-android-application/67288/4

The problem here is that the auth0 logs is telling to add "<app_id>:///capacitor/<app_id>/callback" as an Allowed origin, which leads to a much dificult error.

[tfmark]

Gonna close this out, last few days looks like it's behaving as it should. Cheers!