Partitioning Login Flows in a Single Auth0 Tenant

[serpa]

Hello Community,

We currently utilize several actions within the login flow of our production tenant, specifically designed to manage internal users within our company. These actions are primarily focused on setting permissions for internal production services.

However, we’ve identified a potential risk where misconfiguration of these actions could inadvertently impact the login flow for our external users. This is a situation we’re keen on avoiding, as these users should remain unaffected by our internal production flows.

This brings us to our query: Is there a way to establish multiple, separate login flows within a single Auth0 tenant? Our aim is to distinctly separate flows for our internal and external users.

Alternatively, would it be recommended to segregate our internal applications into a different tenant and configure the respective login flow there?

We would greatly appreciate any advice, insights, or best practices regarding this concern.

Thank you for your time and assistance!

[peter.fernandez]

@serpa

This brings us to our query: Is there a way to establish multiple, separate login flows within a single Auth0 tenant? Our aim is to distinctly separate flows for our internal and external users.

@serpa

In this case, when you say “separate login flows within a single Auth0 tenent” I’m assuming you’re asking if it’s possible to effectively create separate and isolated Actions partitions within the a single Auth0 Tenant. As in on set of Actions flows - i.e. one Actions partition - which runs for internal users, and another that runs for external users. Correct? Within the context of a single tenant that’s not possible; it would effectively, as you say, require a separate Auth0 Tenant instance to achieve.

Alternatively, would it be recommended to segregate our internal applications into a different tenant and configure the respective login flow there?

So yes, a separate Auth0 Tenant would effectively allow you to achieve complete isolation. And you would be achieving complete isolation across the board: not just an isolated extensibility environment, but isolated configuration, isolated deployment, and an isolated user profile store too. There are numerous advantages to this. However it may prove challenging if there is overlap in your user communities (i.e. where “internal” users can not also be “external” users and vice versa). In that case, the difficulty which arrises for a user who may have multiple personas - e.g. both an “internal” user persona and an “external” user persona - is when you want to maintain a single user profile (for that user). Whilst Auth0 provides User Account Linking functionality, this only works intra Auth0 Tenant and not inter Auth0 Tenant.

Hope this helps