I am using Classic Universal Login Experience with Auth0 Lock v11 and Username-Password-Database.
I would like to block login with unverified accounts (which are not email-verified yet) at Lock UI, rather than blocking the login process by our application.
I know that Auth0 Lock UI can handle “wrong user account and password” at Lock UI, for example, no account in the database, un-match password with the existing account.
I would like to implement the same blocking behavior for the unverified account at Lock UI.
Could you please suggest your advice to achieve my expected behavior ?
Thanks in advance.
Best regards,
-Shige
Shige Fukushima
I had already tried this rule to block the user login. But, this does not provide our expected behavior.
Because the solution with this rule does not block the user login at Lock UI experience itself and this makes “callback” to the registered callback URL with “?error=unauthorized&error_description=…” query parameter.
According to our investigation with the rule solution, actually, the login (https://.au.auth0.com/usernamepassword/login) was successfully done even with this rule solution, since we observed that “last login” was updated and login counts was updated to “1” even if the Rule blocked login. Then callback (https://.au.auth0.com/login/callback) was called.
The experience what we would like to achieve is to show an error message in Lock UI.
For example, if you input wrong username/password, the login (https://.au.auth0.com/usernamepassword/login) returns an error and the “callback” will not be called in this case and keep showing Lock UI with error message. I would like to achieve this behavior for this un-verified account.
This isn’t a built in feature in lock, if you absolutely need this flow you will need a custom login page. There are other solutions, like using a rule, or a redirect from a rule, but those happen after leaving the lock UI.
How are users going to request a new verification email?
Hi @dan.woda,
Thank you for your reply.
(Sorry for many edits)
We are considering the following UI operation process, if we can:
A user will sign-up from our mobile app (Universal Login with Lock UI) with a user’s email address and password (and with First/Last name in a custom additional form via Lock UI).
We send a verification email to the user from Auth0 platform (with our external email provider) after the user’s sign-up.
We also show the Lock UI in our mobile app with the message, “Thanks for signing up. Please check our email to verify your email.” ; this can be done with “loginAfterSignup: false” option configuration in Lock UI to block automatic login after sign-up. We don’t know if we can customize the message in the UI.
The user will go to an email app to verify his/her email and open an email verification link (which we sent via verification email) via any browser.
The user will go back to our mobile app to go back to the login form ; if we can show login form in our mobile app automatically after step #4, that’s great. Or If we can customize “Thanks for signing up” dialog of Lock UI to add a link to go back to “Login form”, that’s great also.
After email verification, then the user will fill username/password to login and he/she can login.
If the user will skip step #4 or input invalid email for the registration at step #1, we would like to block any login of the registered user from our mobile app, and we want to tell the situation to the user more explicitly at Lock UI (or login UI) with a message like “Your email is not verified yet, and please find your email verification link in our email we have sent.” etc. etc.
I think that it’s more understandable for end-users (from the user experience perspective) if this feedback will happen at login form. Also we don’t like to make the app responsible to handle such detailed situation, in order to separate the role of app codes.
That’s why we are seeking a solution in Lock UI, since Lock UI is very nice.
Also, if users in the username/password database will keep the login state “never” more than two weeks (14 days), we want to remove the users automatically via Auth0 Management APIs. The rule solution will make the login count up even before the email verification.
The rule solution you suggested in your first reply will not match with this objective. Because your auth0 internal logic actually “allows” the “login” to accounts even with unverified email (this means you can register your account with any wrong or non-existing email address - because the email verification is not required by default). Please see the screenshots below to confirm the login count and pending state of the account.
If my understanding is correct, the root cause of our problem is:
The login process of Lock UI will call two APIs in our case: 1) https://tenant name.au.auth0.com/usernamepassword/login, then 2) https://tenant_name.au.auth0.com/login/callback
The custom Rule for blocking unverified email account makes an effect to the second callback API to return an login error, but no effect to the first API (login).
API call of https://tenant_name.au.auth0.com/usernamepassword/login will return a successful result even with unverified email account.
Then the Lock UI will call the second API (callback) and will return the login error.
If we can customize a kind of hook in the first API (https://tenant name.au.auth0.com/usernamepassword/login) above, then it seems that we can achieve what we want.
Thanks for the detailed breakdown. I’ll try to expand on what I mentioned in my other reply.
This type of flow is not built-in to Lock and you will need a custom login page to display an “email not verified” error directly in a login box. You won’t be able to use Lock for this.
As I mentioned, there are ways around this. For instance, you can use a redirect within a rule to redirect an unverified user to a holding page or error page that says they must verify before continuing. You can also still accomplish your requirement of deleting unverified users after 14 days, by simply looking at email_verified and created_at, there is no need to look at their login count.
Using Lock is going to require some level of flexibility in your login flow requirements, and although it is quite extensible, it obviously cannot cover every flow.
