I am investigating the use of various flows using Auth0. I am wondering if the question in my topic title is possible?
For example, can I redirect joe@acme.com back to the old non-Auth0 login page - while allowing pete@example.com to login using the Universal login page? This would greatly facilitate a staged migration.
It would probably be easier to do this from your application than from the hosted login page. We support realm discovery, but it wont point the user away from Auth0.
Thanks for the quick reply @dan.woda. Much appreciated!
The problem with doing this from my application is that it would put the decision making in my application. Whereas it is more desirable to use the Universal Login page - and related Auth0 connections - as the source of auth decision making (as much as possible, of course).
I have taken a look at some other docs and forum posts. How about this solutionâŠ
Have a Auth0 Database connection, elect to âUse my own databaseâ under the Custom Database settings, then add a Login script with something like the following pseudocode:
if USER_BELONGS_TO_SOME_LEGACY_DOMAIN {
const deniedProfile = {
user_id: some_generated_user_id // note: user_id is mandatory, even here
email: email,
reject_login_attempt: true // NB: This can be checked in a rule later
};
callback(null, deniedProfile);
}
else {
// Attempt to authenicate the user and build a valid profile and then...
callback(null, profile);
}
And then in an Auth0 rule do something likeâŠ
if (user.reject_login_attempt) {
context.redirect = {
url: "https://legacy_auth_server/old_login_page"
};
return callback(null, null, context); // It may make sense to pass user as the 2nd arg here instead of null
} else {
return callback(null, user, context);
}
@dan.woda Does that seem reasonable? Are there some pitfalls with this approach? I notice that the user still appears in the list of users in Auth0 - is it possible to prevent this?
That seems like quite a workaround. You are effectively logging the user in before they provide credentials. Also, redirect rules are meant to redirect away from the rule and then return back to the rules flow after the redirect action is completed.
You have part-answered my implied question which is, âDoes this mean that the user is effectively logged inâ?
From your reply, my understanding is now that the user is effectively logged in.
When I tested the approach, I did not see any âsuccessful loginâ in the Auth0 logs so that suggested that the user wasnât successfully logged in. I think that was the case - even if I passed user as a second argument to callback(null, null, context) - though I would need to double-check that. The fact that they appeared in the users list made me think that this is indeed effectively a login - and you have now confirmed that.
As regards where I saw this recommended, I wouldnât go as far as to say that it was recommended for a legacy login page use case - I just saw â keep a white-list of users and deny access based on emailâ at Auth0 Rules and decided to investigate what âdenyâ exactly meant. Now, I know the answer.
I want to redirect the user to another url if the login attempt is failed.
and
In case of login failure, it shows âWrong email or passwordâ in the Auth0 login dialogue itself. Instead of showing this message, I want to redirect the user to our custom page if login fails
(The redirect URL desired by the forum poster is not an alternative legacy login page of course.)
Ideally, from my use caseâs perspective, the best solution would be if there is another type of connection in Auth0 - and using this connection type (letâs call it a Simple Redirect Connection) you could redirect based on a JS script or configuration. That would allow the user to be redirected to a legacy login page if they fitted certain criteria - similar to the âloginâ script in the custom database connection (but it would get rid of the password field as soon as the criteria were met). I guess nothing like this exists?
I made this statement a bit casually. It is not that the user is logging in, but rather that they are being authenticated without providing credentials. This is why you see a user profile, but not a successful login (they never complete the login).
This isnât quite a connection. Your legacy login page is not an identity provider passing a token or profile back to Auth0, then Auth0 issuing a token. It is simply redirecting to a separate login page. That is if I understand everything correctly.
Using a Custom Database to bypass authentication, then redirecting from a rule without resuming does not seem like a viable solution for this. It may work, but you are going to be creating user profiles every time you do this. It is quite a workaround.
You are correct in your rephrasing of what I was asking for here. And you are correct in saying that it âisnât quite a connectionâ.
Iâll consider looking into this.
Completely agree with you. Putting this esoteric solution up for discussion has helped me understand what is possible and what isnât, as well as what is appropriate and what isnât. Thanks again.