Auth0 is a SaaS identity provider that lets you add production-grade authentication to your product quickly. It offers two main flavours: Business-to-Consumer (B2C) and Business-to-Business (B2B).
\nToday, we’re focusing on the B2B use case.
\nAuth0 B2B revolves around Organizations: a model you can use to represent your own tenants, companies, or organisations. You can map users to one or more organisations, assign them different roles inside each one, and enable SSO connections, complete with domain discovery, on a per-organisation basis.
\nAn Auth0 application can be configured for one of three login experiences:
\nIf you’re building a B2B product with SSO or multi-tenant requirements, you’ll want to use Organizations together with the Business users login flow. This combination handles most of the hard work for you, letting Auth0 handle invitations, self-service SSO configuration, and providing org selection after login for multi-tenant systems, but it comes with a catch: when an application is set to Business users, a brand-new customer can sign up and then immediately be unable to log in, because they don’t yet belong to any organisation.
\nThere are two common ways around this.
\nThe first is to let new users create an organisation before they authenticate, then redirect them to sign up against that organisation. This has a couple of serious drawbacks. First, it requires an unauthenticated endpoint that lets anyone create organisations, which an attacker could use to flood both your database and your Auth0 organisation-usage limits. Second, if the user abandons the flow, or if anything goes wrong between creating the organisation and linking the user account, you end up with ghost organisations and frustrated users who have to start over.
\nThe second approach, which we’ll cover today, is to have the user create their Auth0 account first, sign in, and then enter an onboarding flow where they provide their personal details and create their organisation. This avoids the pitfalls above, but it isn’t the immediately obvious solution, and Auth0 doesn’t document it in one place. Let’s look at how to build it.
\nThe solution to the problem is actually quite simple once you realise all it takes is three Auth0 applications, a bit of redirection through your frontend based on the user’s state, and some Auth0 Management API calls from your backend.
\n“Why three Auth0 applications?" I hear you say. Well, we need two applications so one can act as an “individual” login application, allowing a user without an organisation to log in, whilst the other acts as the primary application, running the “business users” login flow so we get access to the org selection screen if needed, and the automatic attaching of the org_id claim on the user’s access token. Lastly, we need an M2M application set up to access the Management API so we can create the user’s organisation and attach them to it.
“Why can’t we just use the ‘Both’ login flow?" You can! And if you do, it makes life simpler; however, you end up with either an annoying “Personal login” button under the login screen, or you end up with users always needing to select either “Personal account” or “Organisation 1” when they log in, which is just a bit shit for a B2B application, isn’t it. If you are happy with that compromise, or your application works with both types of users, then go for it!
\nSo to start, let’s set up our Auth0 applications. I will be using the Auth0 Dashboard to do all the Auth0 setup, but everything can be replicated using the Deploy CLI if you are already using it or if you want to start using it. I will also be working with a TanStack Start application, but again, everything should be replicable for any other frontend setup.
\nFirst, let’s set up our onboarding application. Create a new application in Auth0 — for our example I will be creating a regular web application. Once created, set the allowed callback URL to http://localhost:5173/auth/callback/onboarding. The default login flow is for Individuals, but you should validate this by checking the Login Experience tab. You don’t need to set up anything else specifically for this setup, so feel free to add any other config you need, like access to specific APIs or specific allowed origins for CORS.
Next, we will set up another application, main, which we will configure a bit more. Again, I will be creating a regular web application, and we will add http://localhost:5173/auth/callback/main to the allowed callback URLs. We will also want to change the Login Experience to Business users with the login flow of Prompt for credentials.
![\"Auth0](\"https://eu.uploads.micro.blog/283069/2026/image.png\")
\nAgain, you can set up any other configuration you need to, like API access.
\nLastly, let’s set up the machine-to-machine client so we can call the Management API. Create a new M2M application — I named mine Management M2M. Once it’s created, navigate to API access and open the Management API permissions setup. We are going to give this client the following scopes under Client access:
\nread:users, update:userscreate:organizations, update:organizationscreate:organization_memberscreate:organization_connections, read:organization_connections, update:organization_connectionscreate:organization_member_rolesOnce you’ve set these up, hit save!
\n![\"Auth0](\"https://eu.uploads.micro.blog/283069/2026/f0e6f5c50a.png\")
\nWe will also want to set up some roles in Auth0 that we will assign to users during signup. To do this, navigate to the Roles section under User management. We will add two roles today, administrator and member. Make a note of both role IDs — we will use these later.
\nNow that Auth0 is set up, let’s move on to the frontend and backend setup.
\nLet’s go over the API endpoints we will be creating for onboarding. I’m going to keep these simple, focusing on Auth0 calls more than anything else. They are also written in C#, but the concepts are the same.
\nFirst, the environment or configuration variables you will use to interact with Auth0:
\nAuth0__Domain=auth0 tenant domain or custom domain if you have one\nAuth0__Audience=audience # only if you have set one up\nAuth0__ManagementClient__ClientId=m2m client id\nAuth0__ManagementClient__ClientSecret=m2m client secret\nAuth0__ManagementClient__Domain=auth0 tenant domain\nAuth0__AppClient__ClientId=main client id\nAuth0__AppClient__RedirectUri="http://localhost:5173/auth/callback/main"\nAuth0__DbConnection__ConnectionId=auth0 database connection id\nAuth0__DbConnection__ConnectionName="Username-Password-Authentication"\nAuth0__Roles__Admin=administrator role id\nAuth0__Roles__Member=member role id\nYou can find your database connection ID by going to Authentication → Database → Username-Password-Authentication in the Auth0 Dashboard.
\nNow let’s create a POST /users endpoint that will be used to create the user record in our database and update the user details in Auth0 so their name is available on the ID token.
[HttpPost]\npublic async Task<ActionResult<Guid>> CreateUser(\n [FromBody] PostUserResourceRepresentation request,\n CancellationToken cancellationToken)\n{\n var auth0UserId = User.GetRequiredUserId();\n // get the "sub" claim from the access token (Auth0 id)\n\n var auth0User = await auth0.Users.GetAsync(\n auth0UserId,\n new GetUserRequestParameters(),\n null,\n cancellationToken);\n\n if (string.IsNullOrEmpty(auth0User?.Email))\n {\n // ... error response as something's gone wrong at Auth0 level\n }\n\n var existingUser = await userRepository.GetUserByAuth0IdAsync(auth0UserId, cancellationToken);\n if (existingUser is not null)\n {\n // ... respond with conflict/bad request etc.\n }\n\n var user = UserBuilder.From(request, auth0User.Email, auth0UserId);\n\n await userRepository.CreateUserAsync(user, cancellationToken); // create user in your db\n\n await auth0.Users.UpdateAsync(\n auth0UserId,\n new UpdateUserRequestContent\n {\n GivenName = request.FirstName,\n FamilyName = request.LastName,\n Name = $"{request.FirstName} {request.LastName}"\n },\n cancellationToken: cancellationToken); // update user details in Auth0 for the ID token\n\n return CreatedAtAction(nameof(GetById), new { id = user.Id }, user.Id);\n}\nThe user endpoint is pretty simple; nothing to note here.
\nNext, let’s add the POST /organisations endpoint we will use to create the new organisation and link the user to it.
[HttpPost]\n[Authorize]\npublic async Task<ActionResult<OrganisationResponse>> CreateOrganisation(\n [FromBody] CreateOrganisationRequest request)\n{\n var auth0UserId = User.FindFirst("sub")?.Value;\n if (auth0UserId is null)\n return Unauthorized();\n\n // 1. Persist the organisation locally\n var org = new Organisation\n {\n Id = Guid.NewGuid(),\n Name = request.Name,\n CreatedAt = DateTime.UtcNow\n };\n\n await _orgs.AddAsync(org); // save to db\n\n // 2. Create the matching Auth0 organisation\n var auth0Org = await _auth0.Organizations.CreateAsync(new()\n {\n Name = $"org-{org.Id:N}",\n DisplayName = request.Name\n });\n\n org.Auth0OrgId = auth0Org.Id;\n await _orgs.UpdateAsync(org); // map Auth0 id to db record\n\n // 3. Add the calling user as a member and make them admin\n await _auth0.Organizations.Members.CreateAsync(auth0Org.Id, new()\n {\n Members = [auth0UserId]\n }); // add the current user to the Auth0 org\n\n var adminRoleId = _config["Auth0:Roles:Admin"];\n\n await _auth0.Organizations.Members.Roles.AssignAsync(\n auth0Org.Id,\n auth0UserId,\n new() { Roles = [adminRoleId] }\n ); // make the user an administrator for this org\n\n // 4. Record membership in your own database\n var user = await _users.GetByAuth0IdAsync(auth0UserId);\n user.AddOrganisation(org.Id, OrganisationRole.Admin);\n await _users.UpdateAsync(user);\n\n // 5. Return a URL the frontend redirects to so the user logs into the org\n var redirectUrl = BuildAuth0RedirectUrl(auth0Org.Id);\n\n return CreatedAtAction(\n nameof(GetOrganisation),\n new { id = org.Id },\n new OrganisationResponse(org.Id, org.Name, redirectUrl));\n}\n\nprivate string BuildAuth0RedirectUrl(string auth0OrgId)\n{\n var domain = _config["Auth0:Domain"];\n var clientId = _config["Auth0:MainApp:ClientId"];\n var redirectUri = Uri.EscapeDataString(_config["Auth0:MainApp:RedirectUri"]!);\n var connection = Uri.EscapeDataString(_config["Auth0:DbConnectionName"]!);\n\n return "https://" +\n $"{domain}/authorize" +\n $"?organization={auth0OrgId}" +\n $"&connection={connection}" +\n $"&client_id={clientId}" +\n $"&redirect_uri={redirectUri}" +\n "&response_type=code" +\n $"&scope={Uri.EscapeDataString("openid profile email offline_access")}";\n}\nThis endpoint will return a response like:
\n{\n "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",\n "name": "Acme Ltd",\n "redirect": "https://your-tenant.us.auth0.com/authorize?organization=org_abc123&connection=Username-Password-Authentication&client_id=MAIN_CLIENT_ID&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&response_type=code&scope=openid%20profile%20email%20offline_access"\n}\n“Why are we returning a redirect URL?" We return a redirect URL from the API because we need to get the user to log in to Auth0 against this new organisation. This login will happen against the main client, which has the Business users flow, and will mean the user’s token has the org_id claim.
That’s our API endpoints sorted — very simple for user details, fairly simple for organisation details. You can extend these as much as you want. For example, in a production setup we should roll back the organisation database record if the Auth0 organisation can’t be created.
\nLet’s move on to the frontend application next.
\nFirst, the environment variables we need, like we did with the API:
\n# Auth0 credentials - obtain from https://manage.auth0.com\n# Main application (Business Users / organization_usage: require)\nAUTH0_DOMAIN=auth0 tenant domain or custom domain\nAUTH0_CLIENT_ID=main client id\nAUTH0_CLIENT_SECRET=main client secret\nAUTH0_AUDIENCE=audience if set up\n\n# Onboarding Auth0 application (Individuals / organization_usage: deny)\nAUTH0_ONBOARDING_CLIENT_ID=onboarding client id\nAUTH0_ONBOARDING_CLIENT_SECRET=onboarding client secret\n\n# Cookie encryption secret\nAUTH0_SECRET=random value, generate with: openssl rand -hex 32\nNext, install the Auth0 package we will be using:
\npnpm install @auth0/auth0-server-js\nTanStack Start isn’t quite fully released yet, so Auth0 haven’t set up a package specifically for it like they have for Next, so we need to do some of it ourselves.
\nNow that our environment variables are set up and we have the Auth0 server package installed, let’s set up the Auth0 clients. Both Auth0 clients share the same session store and cookie encryption secret, but they each have their own client ID, secret, and redirect URI, so we need a factory.
\nCreate a new file under src/lib/auth.server.ts:
import {\n CookieTransactionStore,\n ServerClient,\n StatefulStateStore,\n} from "@auth0/auth0-server-js";\nimport { env } from "cloudflare:workers";\n\nexport type Auth0Mode = "main" | "onboarding";\n\nconst auth0Clients: Record<Auth0Mode, ServerClient<void> | undefined> = {\n main: undefined,\n onboarding: undefined,\n};\n\nconst secret = process.env["AUTH0_SECRET"] as string;\nconst sessionStore = new KvSessionStore(env.AUTH_SESSIONS); // or your own store\n\nfunction getClientConfig(mode: Auth0Mode) {\n const appUrl = process.env["APP_URL"] as string;\n\n if (mode === "main") {\n return {\n clientId: process.env["AUTH0_CLIENT_ID"] as string,\n clientSecret: process.env["AUTH0_CLIENT_SECRET"] as string,\n redirectUri: `${appUrl}/auth/callback/main`,\n };\n }\n\n return {\n clientId: process.env["AUTH0_ONBOARDING_CLIENT_ID"] as string,\n clientSecret: process.env["AUTH0_ONBOARDING_CLIENT_SECRET"] as string,\n redirectUri: `${appUrl}/auth/callback/onboarding`,\n };\n}\n\nexport function getAuth0(mode: Auth0Mode): ServerClient<void> {\n if (!auth0Clients[mode]) {\n const { clientId, clientSecret, redirectUri } = getClientConfig(mode);\n\n auth0Clients[mode] = new ServerClient<void>({\n domain: process.env["AUTH0_DOMAIN"] as string,\n clientId,\n clientSecret,\n authorizationParams: {\n redirect_uri: redirectUri,\n audience: process.env["AUTH0_AUDIENCE"] as string,\n scope: "openid profile email offline_access",\n },\n // These two stores are framework-specific; the key point is that\n // both clients can share the same underlying session storage.\n transactionStore: new CookieTransactionStore({ secret }),\n stateStore: new StatefulStateStore({ secret, store: sessionStore }),\n });\n }\n\n return auth0Clients[mode];\n}\nBecause both clients use the same session cookie name, the latest login naturally overwrites the previous one. The lifecycle is always Onboarding → Main.
\nNext, let’s set up our signup and login routes:
\n// src/routes/auth/login.tsx (Normal login)\nconst startLogin = createServerFn({ method: "GET" }).handler(async () => {\n const url = await getAuth0("main").startInteractiveLogin();\n throw redirect({ href: url.href });\n});\n// src/routes/auth/signup.tsx\nconst startSignup = createServerFn({ method: "GET" }).handler(async () => {\n const url = await getAuth0("onboarding").startInteractiveLogin({\n authorizationParams: { screen_hint: "signup" },\n });\n throw redirect({ href: url.href });\n});\n\nconst startOnboardingLogin = createServerFn({ method: "GET" }).handler(async () => {\n const url = await getAuth0("onboarding").startInteractiveLogin({\n authorizationParams: { prompt: "login" },\n });\n throw redirect({ href: url.href });\n});\n\nexport const Route = createFileRoute("/auth/signup")({\n preload: false,\n loader: ({ location }) => {\n const mode =\n typeof location.search === "object" &&\n location.search !== null &&\n (location.search as Record<string, unknown>)["mode"] === "login"\n ? "login"\n : "signup";\n\n return mode === "login" ? startOnboardingLogin() : startSignup();\n },\n});\nNotice that each endpoint uses a different client: onboarding for signup, and main for actual login. Remember why we do this: the main client will prevent new signups from logging in because they aren’t part of an organisation yet (we’ll deal with aborted onboarding later). The onboarding client allows a new user to log in without being part of an organisation.
\nNext, let’s add our callback routes so we can handle token requests.
\n// src/routes/auth/callback/main.tsx\nconst handleMainCallback = createServerFn({ method: "GET" }).handler(async () => {\n const url = getRequestUrl();\n\n const error = url.searchParams.get("error");\n const description = url.searchParams.get("error_description") ?? "";\n\n // The user has an Auth0 account but isn't a member of any organisation yet.\n if (\n error === "invalid_request" &&\n description.includes("client requires organization membership")\n ) {\n throw redirect({ to: "/auth/signup", search: { mode: "login" } });\n }\n\n await getAuth0("main").completeInteractiveLogin(url);\n\n // Redirect to the main application\n throw redirect({ to: "/" });\n});\nIn this callback we capture any errors from Auth0 post-login. If a user logs in and they don’t have an organisation, Auth0 will return an error containing the string client requires organization membership. When we see that, we redirect the user to log in through the onboarding client again, which forces them back down the onboarding flow.
// src/routes/auth/callback/onboarding.tsx\nconst handleOnboardingCallback = createServerFn({ method: "GET" }).handler(\n async () => {\n const url = getRequestUrl();\n await getAuth0("onboarding").completeInteractiveLogin(url);\n throw redirect({ to: "/onboarding" });\n },\n);\nWe always redirect to /onboarding if a user logs in using the onboarding client. /onboarding will eventually redirect the user back to the actual app once they’ve set up their user and organisation, so even if an already-onboarded user goes down this flow they will naturally end up in the right place.
Now when a new user signs up, they will log in and go through the onboarding process, which is protected from malicious spamming through authentication! You are free to set up these screens however you like; the only thing you need to follow is the order, which should be set up user → set up organisation.
\n“Why do I need to do it in this order?" Remember the API endpoints: the POST /organisations endpoint returns an object including a redirect URI that will direct the user to log in to the newly created organisation. You could swap the flow and return the redirect from the user endpoint, but it doesn’t make sense to a consumer, and you would have extra work to fetch the organisation from the DB to retrieve the Auth0 ID to then pass down to the redirect.
So now we’ve gone over that, once the user has finished onboarding we will use the redirect. Simply take the redirect URL from the POST /organisations response and do:
const result = await response.json();\nwindow.location.href = result.redirect;\nThis will redirect the user back to Auth0, which will then log them into the organisation and send them back to the main app callback!
\nThat is the whole setup finished! A new user can now sign up, log in, onboard, and get into their organisation, being directed back to onboarding on the next login if they abandon it mid-journey.
\n", "date_published": "2026-06-19T22:39:52+01:00", "url": "https://benrants.com/2026/06/19/auth-organisations-self-service-signup.html", "tags": ["auth0"] } ] }