Description: A pre-login Action for email/password-based login attempts would be very, very helpful for us for achieving user migration over to Auth0. We would like to be able to have an action executed before the password entered by users is verified.
Use-case: Our use-case is user migration. In the pre-login Action, we would like to start a re-authentication process that ends with the user being able to set a password for their not yet activated account. We imagine the pre-login Action in our case to check if the user is trying to log in to a newly migrated account, i.e., an account with an email address that is in some way marked as not activated, yet. If we identify a login attempt to a not yet activated account in the pre-login Action, we abort the login process w/o verifying the password, send an email to the email address of the not yet activated account, and redirect the user back to a page on our side that says they should check their email account for an account activation email.
Because such a pre-login Action does not exist, yet, we have to send out many, many account activation emails to our users and hope that they do not ignore it.
Conditionally block the authentication flow if the email or phone number doesn’t exist. This data could be queried on a user via an auth0 linked account, auth0 user metadata or a custom database with other user data.
This would also prevent unnecessarily sending SMS or Emails and to avoid an attack vector that spams random phone numbers and emails with verification code messages.
It’s essentially a building an action to block authentication from a /passwordless/start API call based on an arbitrary condition.
Edit: Current workaround is to use the management API to check if a user exists with that email or phone number (or other conditions) before invoking the /passwordless/start flow.
This obviously opens up a fairly obvious attack vector on my API since it would be difficult to secure this endpoint.
@dan.woda are you able to provide any visibility on this or share a roadmap of feature releases in the coming months / year?
We would also like to have this feature. We have users that login via email/password, but if they are in certain email domains, we want to force them to use the SSO sign in option. As it is now, we can’t show the error on the login page and have to show them an error on a completely different page and then require them to go back to the login page to use the SSO option. Very inconvenient compared to when new users are registering, we can catch those situations (pre-registration action) and show an error on the login page itself asking the user to use the SSO login option.
@dan.woda Are there any plans to have this pre-login action any time soon?
Would like to second the point made by chris.bohn.
We want to catch login attempts based on domain and provide feedback to the customer about the login process, such as Logging in with Google Auth instead of username/password.
@dan.woda Is this feature on the product development timeline? Do we have any insight about when this would be available?
It would be a huge help to many of the Auth0 developers and companies looking for something like this to improve the flow for our customers.
@skylar, we don’t currently have a pre-login trigger on the roadmap, but there are plans for a post-identifier trigger that would likely cover this use case. I don’t have any hard dates for it, but would expect to hear more in our Customer Identity Cloud: Roadmap and Feature Releases webinar.
Thank you for sharing the Video Dan!
I reviewed the video you liked and saw the note about the post-identify trigger at the 30-minute mark. I didn’t get a good handle on what that would give us the option to do. Can you share more about how that will work?
Also, can you tell me when the video was released?
The post identifier trigger will happen after a user has submitted their identifier (typically email), but before credentials are authenticated. I’m not 100% sure, but it sounds like this would address the use case described in chris’s post.
@Skylar Sorry this is a bit late, the pertinent part is that the post-identifier trigger is in our roadmap, so you will not find documentation for it as yet as it’s unreleased:
