They run off the same code base but some branding & features are dynamically generated/toggled, and later one we also intend to be able to have the brands use their own domain.
So I’m just wondering if we should have one “Example App” at the “Application” level and then the brands at the “Organization” level? Or does it make more sense to have the “Example App” at the account/tenant level and then to have each brand as a separate “Application” within Auth0 and then just ignore organizations.
There will also be some custom branding via templates for the Universal Login (login, password-reset, etc), which seem to get the “client_id” for “Application” injected as part of the config. The separate brands will also have some SSO features, so it will be one database connection they all share.
Any insight on how best to logically structure this would be greatly appreciated.
There are a multitude of options to consider, but generally speaking it seems like 1 tenant → 1 Application → Multiple Organizations might be your best bet.
I definitely recommend checking out our docs on B2B Architecture:
Hope this helps at least get you started in the right direction
Thx for the update, I read through the docs, and this does make sense, however I’m looking for a more actionable solution to try here.
I’m still having trouble with the branding. So with organizations the login pages seem to be branded, however it’s not possible to brand with the register page as far as we can tell. If we include the “organization” param on the register page it just shows us an error page.
So it’s a bit strange for us to have a branded app that then redirects to a centralized register of some other service/brand which would be very confusing for our customers who have no idea that there is an underlying app/service there.
I’ve tried approaching this with custom templates, but it throws an error page when an organization is included in the url (note I’ve substituted all example values in the url below):
If I remove the “organization” param it goes through, but then how is it possible to brand by org/brand if no unique identifier is there? I’ve also tried adding a “state” param to the url/request, but I don’t see any of that getting propagated to the config when I console it out in the Universal Login Template.
This is why I thought I might use “Application” for each brand as I can get a unique client_id there, but as you suggest, this is not correct?
Really unsure how we can do custom branding here for the register page or with Universal Login templates. Is there some other way to pass a unique identifier to represent a brand in for the templates or make sure each of the default pages are branded including the register page?
