I’m running in to an odd problem, and I’m not sure how Auth0 organizations are supposed to work in this context: primarily the sign-up use case.
What’s the recommended flow for sign-ups when using organizations, in contexts where users can sign up on their own? When a new user signs up, they WONT be in an organization.
From this point, I seem to have a few different options.
OPTION 0:
Use an application that allows “BOTH” individual users and org users. This really doesn’t work because the Auth0 sign-in/sign-up experience shows this extra option where a user can sign in via a “personal” account, or they can pick an org they’re a member of.
Our app relies on org information, so we don’t want them to be able to pick a “personal” option, ever. We can’t use the BOTH option.
OPTION 1
Create two applications, one that is only for “Individuals” and one for “Business Users” - this means our UI has to juggle which application to authorize against, based on which part of the app they’re in. If they’re in sign-up, you use the individuals app. If you’re anywhere in the app, you use the business app.
OPTION 2
Create a login-hook that auto-creates some sort of “skeleton” org, and put the new user in that empty org. This seems not-great too - it means a bunch of extra/orphaned data that doesn’t correspond to organization information on our apps side. This empty/starter/orphan org would also be present in the org list shown during login.
We have proceeded with our app set for “BOTH” individuals and org users. Now, once a user signs in, the app fetches a list of the user’s memberships from a facade layer built on top of Auth0 and issues a second access token picking the org id either from the user’s local storage or the first item of the memberships list. As far as sign ups are concerned, we onboard users utilising Auth0’s invitation flow and we will be soon building a user management UI speaking to the facade layer where org managers will be able to manage the users of their orgs. Upon sign up, a user will not be a member of an org so the app prompts them a relevant error message. Last, keep in mind that access tokens are also carrying the org_id and that’s how the app can actually identify the different use cases. A little complex but it kinda works. Curious to hear about alternative approaches though.
I know this is a very old post, but I’m running into this same issue now. Is there any chance you could elaborate on this “facade layer” that helps skip the organization picker?
I’m using the new universal login and am having trouble figuring out how to hook into the part of the lifecycle in between the user submitting their credentials and selecting their organization. I thought about using the Auth0 actions or their new flows, but both run off of the post-login trigger, which appears to be hit after the user selects their org.
Yep sure let me elaborate. By facade layer I am referring to a custom built API layer/service allowing other services to be Auth0-agnostic. This not only helps us respect Auth0’s quotas by consolidating requests but also makes our system more flexible—if we ever need to switch providers or expand our authentication infrastructure, our other services won’t need to be reconfigured individually. On the cons with this approach: 1) you get yet another hop and 2) it needs some implementation time