From the Universal Login page, is it possible to redirect a user with a specific domain to an old non-Auth0 login page?

Hi,

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.

Kind regards,
Declan

Hi @declan,

Welcome to the Community!

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);
    }

Resources:

@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?

Kind regards,
Declan

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.

Where are you seeing this recommended?

Thanks @dan.woda.

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 https://auth0.com/docs/rules and decided to investigate what ‘deny’ exactly meant. Now, I know the answer.

Regarding the technique, I saw it here - Redirecting on login failure - where the forum posted initially stated:

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).

Here is a visualization of the login flow. Your user starts the “optional redirect” but never resumes and completes 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.

You could probably do what you originally intended by creating your own UI.

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.

1 Like

Thanks again, Dan, your feedback is great.

Makes perfect sense, thanks.

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’.

:+1: 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.

Glad I was able to provide some level of clarity. Let us know if you run into any issues or have other questions.

Thanks!

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.