We’re looking at using Auth0 for a couple of upcoming projects and previous experience was with StormPath (now part of Okta)… I’m trying to map the approach we’ve used in the past to Auth0.
Basically, past experience was that we had a single user “directory” that had all accounts/credentials in it. We then had multiple applications/environments that used that one directory. Users inside the directory were assigned Roles so that a user could have access to one or more environments for each application. A QA person might get app A’s Test environment, B-Test, C-Test, etc… devs might get A-Dev, A-Test, B-Dev, B-Test, etc… customers get A-Prod, or B-Prod, and so on.
The key was that we had just the one directory so an account in that directory could log in and either choose which app/environment to reach, or they would be auto-directed to an app/environment by going to a specific subdomain and authenticating there… but end of the day, they had one set of credentials to remember and all of those were in the single directory.
We’ve read the docs and it’s not 100% clear how to map this to Auth0… it doesn’t look like a “tenant” is a directory because the explanation we found in the docs is to create a tenant for each environment we need (and presumably each app/environment combination as we had more applications)… if we do that, it looks like a user may have to manage different credentials across apps/environments.
Is it possible to have a single “directory” and then use role/permissions within that to authenticate multiple apps/environments? How does the concept of a “tenant” fit into that approach? (note: ours is not a SaaS or multi-tenant application at all… this is largely an internal workflow system where we want to allow certain types of external access so we’re not just using an internal directory). Thanks.
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.
Hey Mark — thanks, this is very helpful! I think the main thing we were missing was the idea of the database connection as the “directory” but your explanation of “Auth0 as the hub” clarifies. Thanks again!