Using Organizations

[spennada]

I’m designing an Auth0 implementation for a B2B service business and would appreciate feedback on my approach.

Business context:

• We provide a service to business accounts — sometimes an individual, sometimes a small group, sometimes a full company

• Current auth is AD LDS with a single “owner” role for customers

• We have multiple apps:

  • Main app — serves existing customers (account management, service booking) and pre-customers (submit interest, work with sales before becoming
    customers)
  • API consumer portal — separate app where company accounts manage their API keys and programmatic access
  • Vendor apps — separate apps where vendors (e.g., catering, rental services) log in to update their offerings/inventory

• We may need federated SSO for some company accounts in the future

• A user can belong to multiple orgs (e.g., someone could be in a vendor org AND a customer org)

• Each app restricts access based on org type — e.g., the main app rejects users who aren’t in at least one customer-related org

My proposed approach:

1. One “general” organization for all individual customers and pre-customers who don’t have a dedicated company org
2. Dedicated orgs for companies needing SSO (e.g., customer-microsoft) with email domain mapped to their IdP connection via Home Realm Discovery
3. Roles for sales funnel progression: lead → prospect → prospect-demo → owner (used to gate UI features in the main app)
4. Vendor orgs (e.g., vendor-catering-co) for vendor-specific apps
5. Users can belong to multiple orgs — a person might be in vendor-catering-co AND customer-general if they’re both a vendor contact and a customer
6. Each app validates org type at login — the main app checks the org claim matches customer-* pattern; vendor apps check for vendor-*; API portal checks
   for orgs with API access enabled

Login flow (main app):

• User hits the main app → /authorize called → if user belongs to only one customer-type org, Auth0 resolves it automatically, no org picker
• If user is in multiple orgs (e.g., a vendor org + a customer org), the app passes the customer org explicitly since it knows which org type it cares
  about
• For federated users, HRD kicks in based on email domain → SSO → lands in their company org

My specific questions:

1. Is a single “general” org for all non-federated customers the right pattern? Or should I avoid a mega-org with potentially thousands of users at
   different lifecycle stages?
2. Is using roles for sales funnel stages (lead, prospect) alongside access roles (owner) going to cause problems? Should I use app_metadata or org-level
   metadata for funnel stage instead?
3. Multi-org membership + app-level org-type restriction — is checking the org claim pattern (e.g., customer-* vs vendor-*) a reasonable authorization
   approach? Or should I use permissions/RBAC per org instead?
4. Org picker avoidance — since a user can be in multiple orgs, but each app only cares about one type, what’s the best way to programmatically select
   the right org? Should the app pass the organization param based on its own knowledge of which org the user belongs to for that context? What if the app
   doesn’t know upfront?
5. Org migration path — when a pre-customer’s company later gets dedicated SSO, I need to move them from the general org to their company org. Are there
   gotchas with the Management API here (token invalidation, sessions)?
6. M2M / API access — what’s the recommended pattern for org-scoped API credentials? Auth0’s client credentials flow is per-application, not per-org. How
   are others handling “give company X their own API credentials scoped to their data”?

Any feedback on the overall architecture or things I’m not considering would be greatly appreciated.

Thanks!

[remus.ivan]

Hi @spennada,

Welcome to the Auth0 Community!

I will try to provide an answer to all of your questions on a high level, so that your desired infrastructure will fit best with Auth0 functionalities.

@spennada

Is a single “general” org for all non-federated customers the right pattern? Or should I avoid a mega-org with potentially thousands of users at
different lifecycle stages?

You should avoid creating a single “mega-org” for all non-federated customers. Organizations are designed as logically isolated boundaries for branding, membership policies, and dedicated identity providers (IdPs) . Forcing thousands of independent individual customers into a single organization means they will share the exact same tenant-level constraints, which degrades system flexibility.

Auth0 natively accommodates hybrid B2B/B2C systems. In your Application Settings under the Organizations tab, you should configure the Login Experience to “Both (Individual & Business Users)” . Individual and pre-sales users will log in directly as standard platform users. Only when an account upgrades to a business account requiring enterprise SSO or explicit tenant separation do you provision an Auth0 Organization and associate those specific users with it.

@spennada

Is using roles for sales funnel stages (lead, prospect) alongside access roles (owner) going to cause problems? Should I use app_metadata or org-level
metadata for funnel stage instead?

Mapping sales lifecycle stages (e.g., lead , prospect ) as Auth0 Roles will cause role-explosion and over-complicate your access policies. Roles should strictly map to actions a user is authorized to perform.

Instead, you can store the customer journey state inside app_metadata , which is secure and cannot be modified by the end-user. Then a Post-Login Action can read this value and append it directly to the ID and Access Tokens as custom claims, as described here - Adding Custom Claims to Tokens.

@spennada

Multi-org membership + app-level org-type restriction — is checking the org claim pattern (e.g., customer-* vs vendor-*) a reasonable authorization
approach? Or should I use permissions/RBAC per org instead?

The robust approach is to tag your organizations with attributes in their custom metadata. You can configure org_metadata on the organization itself such as org_metadata: { "type": "vendor" } to vendor organizations. Then, write an Auth0 Post-Login Action that triggers when a user logs in. The Action can check event.organization.metadata.type against the application they are trying to access via event.client.client_id and if a user from a vendor org tries to log into the main customer app, the Action can immediately block the login using api.access.deny().

@spennada

Org picker avoidance — since a user can be in multiple orgs, but each app only cares about one type, what’s the best way to programmatically select
the right org? Should the app pass the organization param based on its own knowledge of which org the user belongs to for that context? What if the app
doesn’t know upfront?

Here it is a bit more tricky, since if you want to bypass the Auth0 Organization picker, your application must know the context upfront. Auth0’s out-of-the-box Universal Login cannot automatically filter the org picker based on the application being accessed (e.g., it will show both vendor and customer orgs to a user who belongs to both).

To avoid this, your applications must supply the target organization parameter with its org_id dynamically inside the /authorize call. One approach that I could think of would be collect the user’s email address suing your app’s customized interface before initiating the Auth0 redirect, then look up their associated organizations against your database, filter for the organization types valid for the current application context, and silently forward the user to the login screen with the correct organization parameter. Or you could also try filtering based on subdomains and map them to their corresponding org_id on your backend database.

@spennada

Org migration path — when a pre-customer’s company later gets dedicated SSO, I need to move them from the general org to their company org. Are there
gotchas with the Management API here (token invalidation, sessions)?

When promoting an individual pre-customer to a dedicated company organization with enterprise SSO, be aware of two critical operational behaviors:

• Session Lifecycle Management: Adding a user to a new organization or modifying their tenant status via the Management API does not invalidate active user sessions or revoke outstanding access tokens. The client application must explicitly initiate a silent authentication loop (prompt=none ) or force a re-authentication prompt to obtain updated tokens containing the newly minted org_id claim. You can check out our - Work with Tokens and Organizations documentation.
• Identities & Account Linking: If a user transitions from a database connection (username/password) to an Enterprise Connection (e.g., SAML/WS-Fed), Auth0 registers this as a new identity . To ensure their local application data, histories, and permissions persist seamlessly, utilize Auth0’s Account Linking features to link the legacy database profile and the new corporate SSO profile together. Check out the User Account Linking doc.

@spennada

M2M / API access — what’s the recommended pattern for org-scoped API credentials? Auth0’s client credentials flow is per-application, not per-org. How
are others handling “give company X their own API credentials scoped to their data”?

Auth0 natively supports Machine-to-Machine Access for Organizations. This allows you to define distinct API permissions for M2M client applications in the context of specific organizations. Your customer or vendor can generate their own Client ID and Client Secret. When their backend requests a token from your Auth0 /oauth/token endpoint, they must include the organization parameter in their request payload.

I hope this helps and if you have any further questions please let me know!
Best regards,
Remus

[spennada]

Thank you for providing feedback all my questions.

I am trying to understand your answer to the first question.

I understand users who do not need enterprise SSO can stay at the tenant level without any org memberships. Only users who need enterprise SSO, have org memberships.

I know apps have the hybrid login experience option. Under that option I selected “Prompt for Credentials” flow selected.

Now there is two types of users - individuals and business users.

For individual login, its straight forward, they enter their email, password, login. No org, membership no org picker.

For business users, however, after entering their email address, how does Auth0 take them to their SSO? does it look at what orgs the email is part of? or does it only use Home Realm Discovery to do that?
Assuming they login using their SSO connection, now does Auth0 display the org picker showing personal account and org option like in the screenshot below? Do the business users even have a personal account or am I getting confused here?

[spennada]

Regarding the second question about roles.

Lead, prospect and other roles if managed on auth0 side, helps my app to determine which content to show.

I believe you are suggesting using just two roles like owner for customers and pre-owner or something similar for pre-customers.. and then track the specific stage the pre owners are in using the metadata? Is it because if the business keeps changing the stages or keeps adding more, we don’t have to create more roles in Auth0?

And, shouldn’t we store the stage in user’s metadata and not app’s metadata? I don’t understand how we can store that in app’s metadata like you suggested. can you please explain?