I’m scoping out a migration from devise to Auth0 but want to have a clear plan to achieve relative parity with out current user hierarchy. This is a SaaS provider that works with multiple businesses that will each have their own set of rules (ie. text-based MFA vs app-based vs no MFA). This seems like a perfect case for Organizations in Auth0, but please correct me if I’m mistaken here.
The questions is: as a SaaS provider there are user accounts associated with us, like customer success and developer accounts, that need to have admin access to all Organizations. It doesn’t seem like a reasonable approach to add them to each org, plus users can only be logged in to one org at a time, so that sounds like a non-starter.
Is there a way I can implement this? I was thinking via hierarchical Organizations, but I’m seeing mixed messages in the documentation/community about implementing that
Hi @octopushugs
Welcome to the Auth0 Community!
You should not use Organizations to manage your internal SaaS employees (Customer Success, Developers). Auth0 Organizations are strictly flat—there is no native hierarchical structure. The correct approach would be to have your internal staff log in outside the Organization context entirely, and use standard Role-Based Access Control (RBAC) or app_metadata to grant them global “Super Admin” privileges at your application’s backend layer.
-
When your customers log in, your frontend app will trigger the Auth0 login flow and include the organization parameter (or use Organization Prompting).
→ Auth0 returns an Access Token containing an org_id claim.
→ The backend reads the org_id from the token and adds a strict WHERE tenant_id = 'org_id' clause to all database queries, ensuring data isolation.
-
When your Customer Success or Developers log in (perhaps via a hidden /admin portal or a specific “Staff Login” button), your frontend triggers the Auth0 login flow without passing any Organization parameter.
→ They authenticate as standard users in your tenant. The resulting Access Token will not contain an org_id claim.
-
For these internal staff members, you utilize Auth0’s core RBAC or app_metadata . You create a Role in Auth0 called Super Admin (which grants a permission like read:all_tenants ) and assign it to your staff.
-
Your backend validates the incoming token.
→ If the token has an org_id , treat them as a normal customer.
→ If the token lacks an org_id but contains the Super Admin role/permission, your backend bypasses the standard tenant isolation checks. Your app interface can then render a dropdown list of all your clients, allowing the Customer Success rep to view any customer’s data seamlessly without ever re-authenticating.
If I can help you out with anything else, let me know!
Kind Regards,
Nik