Multi-tenancy -- Tenants or Connections?

Help
1

I think I may be getting confused by the fact that Auth0 offers Tenants within an account. Everything I’ve read on Auth0 thus far would seem to indicate that if one is trying to create a multi-tenant application, the preferred method is to do one of the following:

  • use either a single db connection to house all users and then use user app_metadata to provide claims as to which tenant the user is part of.
  • use multiple db connections within a single Auth0 tenant with each db connection representing a tenant of your application.

Initially, I was assuming that I would use a new Auth0 tenant for each of my application tenants. However, it would appear that I would have to re-define my application (both SPA and API) in each tenant – giving them each their own unique ID, etc. That seems less desireable. So what is the purpose of Auth0 tenants and am I correct in my assessment of db connections being the preferred mechanism for multi-tenant applications?

2

An Auth0 tenant organizes all the resources you need to provide IAM services. We (where I work) organize tenants around prod vs. non-prod (which I believe is pretty typical), plus temporary tenants for one-off tests, proof-of-concept work, demos etc.

All our (production) applications have clients (in the OAuth 2.0 sense) in a single tenant with a single user data repository. There may be use cases for multiple production tenants, but I know Auth0 ProSvcs folks have steered us away from “multi-tenant applications”.

2 Likes