Hi @jeff8,
Welcome to the Auth0 Community!
You tenant is a container for all the configuration elements you might use to build your authentication and authorization service. Typically you would probably have one production tenant and one or more non-production tenants. All you real users would exist in your prod tenant only. Users in the non-prod tenant would typically be fake users created by your dev team. I would point test / staging / QA / etc. versions of an app at your prod tenant and use role / attribute-based access control to provision access to those environments, rather than creating new credentials in your non-prod tenant.
The “directory” in Auth0 is a connection, but connections come in many forms and you can have many of them.
- Auth0 hosted databases
- 3rd party databases (SQL, NoSQL, LDAP)
- Enterprise connections (SAML, OIDC, G Suite)
- Social login providers (Google, Facebook, LinkedIn, etc.)
I like to describe this model as “Auth0 as a hub” which connects all your applications / APIs and all your connections (aka user data repositories, aka Identity Providers), and you can map applications / APIs to connections in whatever way makes sense for you. For example, most of our users are stored in an Auth0 database, but we also have SAML connections to partners who want to SSO into our services with their corporate credentials. You can mix and match connections based on your needs.
A database connection is the object most closely equivalent to your “directory” and I suspect is the most commonly used user data repository. It is an Auth0 hosted nosql database (or at least, it presents user profiles as JSON documents).
For roles, you can use Auth0’s core RBAC feature, or you can roll your own solution by storing role data in each user’s profile.
Mark