Better error messages for passwordless login

[ch-angelino]

Describe the problem

Only a single generic error message is available with passwordless login whereas there are some obvious scenarios for failure that will happen on a regular basis. This error message is not particularly helpful to the user in some cases. This error message can be found here and can be statically overridden via the library's languageDictionary option, but not dynamically overridden depending on the context.

Here's 3 examples of errors where a specific error message could be displayed:

1. Entering an invalid code
2. Entering a code that expired
3. Entering an unregistered email address or phone number with Sign Ups disabled

What was the expected behavior?

Instead of the generic error message, a specific error message is displayed to better inform the user of the situation. As a comparison, the login with password offers a lot more error messages.

Reproduction

• On the Auth0 dashboard, go to Authentication > Passwordless

• Turn on Email

• For example 3 only, toggle "Disable Sign Ups" on

• On the Auth0 dashboard, go to Applications > Applications

• Create a native application

• Under Settings > Advanced Settings > Grant type, select Passwordless OTP

• Under Connections, select Passwordless email only

• On the Auth0 dashboard, go to Branding > Universal Login > Login

• Toggle "Customize Login Page" on

• Select the "Lock (passwordless)" template

• Implement a basic client that triggers the Universal Login flow

• For example 1, enter a valid email address and an invalid code

• For example 2, enter a valid email address, wait the default 180 seconds OTP expiry, and enter the valid but expired code

• For example 3, enter any email address

Environment

• Version of this library used: 11.32
• Which framework are you using, if applicable: Flutter
• Other modules/plugins/libraries that might be involved: flutter_appauth

[stevehobbsdev]

Thanks for the report and your patience here. I'll need to take a deeper look into it as we may be at the whim of what the server is sending back to us in terms of errors.

[ewanharris]

@ch-angelino thanks for raising this issue!

I took a deeper look and as @stevehobbsdev indicated we're limited here by the response from the server, for the scenarios you listed the error codes are too generic for us to distinguish specific errors and report better messages back to the user.

I'm going to close this issue as we can't improve on this right now, however I've queried internally to see if this is something we can improve (it's possible that this generic-ness is due to security) and if it's possible we'll look to improve the messages lock provides.