Hi there,
I’m trying to wrap my head around the best way to design this within Auth0 so that I can journey forward with two different projects.
We desire to have a SINGLE user database for customers which can provide access to any number of our customer-focused product offerings. Currently we have one in place for username/password and a few social connectors. This is using the universal login experience with company branding.
When adding secondary applications, we need to be able to -
- Brand the login/signup experience according to the product they’re accessing
- The user must be unaware that there are any other products available via the auth platform (ie. if a user signs up for application A, they should only be aware of and by default only have access to application A)
- Role based access or similar to provide granularity over the applications accessible to the user (ie. if they signed up with application A, their role allows this only; if they sign up with application B, their role allows this only)
- Ability for a user to obtain an additional role - eg. if they have access to application A but sign up for application B, the role is automatically granted
- Have the auth domain being specific to the platform (eg. auth.app1.com for app1; auth.app2.com for app2).
Effectively - I want multiple, independently operating apps with independent users and independent branding, but drawing from a single user database (with appropriate app permissions/assignment) such that providing access to additional applications in future is seamless.
What’s the best way to go about doing this?
Currently we have a single tenant with a single application and a user database and utilising universal login for our first platform, but we need to adjust things so that we can plug in second (and subsequent) platforms ASAP.
Hi @cvglobal 
Welcome to the Auth0 Community 
It sounds like what you have is something often referred to as a multi-site scenario - similar in many ways to a B2B SaaS scenario - and so there are a few things I’d suggest you consider looking at in further detail; I’ll outline these below using the 5 point list you provided as reference:
- Take a look at Auth0 Organizations. This can provide you with easy-to-use branding options as well as an additional context of execution from an Auth perspective. Of course, if you need next-level branding, then Universal Login Template Customization can also be leveraged to achieve this via the likes of Liquid extensibility that allows you to incorporate custom logic.
- Again, Auth0 Organizations can help with this - i.e. via the membership paradigm it employs - and will also allow you to incorporate Invite workflows as part of membership should you need them.
- Auth0 provides RBAC - Role Based Access Control - out of the box as a general capability for all users, and where Auth0 Organization Members can also be assigned particular roles depending on context (see here for more details).
- Auth0 Extensibility can be leveraged to (re)assign role(s) to a user under specific conditions - either adding to the roles a user has or even removing roles where necessary; take a look at the example here for more details. For complex Authorizations that can be challenging with RBAC, Auth0 also offers FGA - which is a relationship-based access control (a.k.a. ReBAC) mechanism that can provide flexibility in addition to the likes of RBAC.
- Auth0 doesn’t currently support multiple (custom) domains, so the model as described won’t work. Instead, consider using a single Auth0 domain - auth.yourcompany.com - and where brand/user management is handled by leveraging the previous points described.
This above should provide you with the ability to configure multiple, independently operating apps with independent users (via membership) and independent branding - all within the same Auth0 Tenant, allowing you to draw from a single user store (with appropriate app permissions/assignment). For additional information, you can read our Auth0 B2B architectural Docs here which also provides access to our Multiple Organization Architecture guidance.
Hope this helps 
Thank you so much for the guidance Peter. I’d already ended up part way down this route.
There will be many challenges with the universal login templates as it may not be customisable enough for our requirements. I would assume that building a fully custom login page as part of our platform would be a supported scenario? What are the challenges to do so? Is there documentation you could point me toward?
Tom
Tom 
Building a fully custom login page within your own platform is a possibility. But it’s one that I wouldn’t recommend. To do something like this, you would need to leverage the Resource Owner Password Flow, which procludes a whole raft of out-of-box functionality in Auth0 - including Passkeys, out-of-box MFA, a number of the Attack Protection features supported by the platform, and any Progressive Profiling to name but a few. 
Resource Owner Password Flow is typically only something we recommend be used in testing scenarios and for applications that can’t leverage browser flows for some reason.
Universal Login Classic Experience would be the next best option. It is still Universal Login, so it supports more out-of-box features than Resource Owner Password Flow does. However, again, I wouldn’t recommend going down this route as whilst it’s currently still available for backward compatibility, it’s considered a legacy technology; Passkeys, for example, are not something it supports, and there are no new updates planned for the functionality it provides.
In all honesty, I would recommend re-visiting the Universal Login (New) Experience, perhaps in conjunction with the Organizations feature I mentioned 
. Whilst the Universal Login templates are maybe not as flexible as they could be currently, there are some new additions planned for 2025 that should give you more flexibility; if you didn’t get to our recent dev_day 2024 event, then take a look at this session recording which will hopefully showcase some of the capabilities to come.
Even so, you can still do a lot today with the templates as they stand, as they do support Liquid Syntax conditional logic; see here for more details. In fact, the login experience for the dev_day 2024 site - see Okta Developer Day - was built using the current out-of-box template mechanism. Also, if you haven’t already tried it, check out the template functionality in the Auth0 CLI, which offers some cool authoring capabilities via the use of Storybook
Hope this helps