We’re currently in the planning stages of our build process for an app that will serve three main categories of users.
Some general notes about what we’re working on:
It’ll be built using node (express) and react.
The app will be a dashboard that has similar features to what you’d expect in any CRM tool. This tool will have two categories of users: internal users and external organization users.
There will be a consumer-facing website which connects to a public API to submit leads to this CRM. This system is not going to have a ‘user context’ whatsoever - people will land on the site, fill out a form, and an AJAX call will occur, sending data directly from the client to the CRM. There will be no intermediary server with a machine-to-machine access token communicating to this API, so we may bypass Auth0 entirely for this portion.
Here’s what we need the app to support:
The app will service internal employees of the primary organization. They can log in and have access to whatever actions / views they need to in order to do their job.
There will be a second category of users: outside organizations. These organizations will have their own users, which have limited access to the app. They’ll all be logging in from the same URL, no custom branding or anything like that.
We need to have an interface in place within our app, for the admin of external organizations to manage the users of their organization, and only their users.
We need to have an interface in place for the admin of the primary organization, to be able to manage all organizations and all users of all organizations.
Users can only belong to one organization, but admin users of the primary organization can see all users and all organizations and manage them.
We are trying to determine what the best way of segmenting users is, in this scenario, with Auth0.
Some questions:
Do all users of all organizations end up in the same database store in Auth0, or do we have to dynamically set up individual database stores in Auth0 for each organization?
What is the best practice here for defining, and segmenting which organization a user belongs to? Is it by tagging users with metadata on signup? How do we do this in a way that cannot be altered?
We will need to have our own database in place to keep a record of all organizations, how is this typically ‘hooked up’ to Auth0 in a way where we can identify all users of any particular organization? Specifically: are we setting up metadata on a user account on signup, and ensuring that metadata value matches a value we have in our database?
In general I would suggest using a single database and differentiating users with metadata. There are use cases for multiple databases but a single DB is simpler to operate.
You can connect pretty much any external database to Auth0 using the custom database feature. If you use a database connection but do not use the custom database feature, then you will be using a database hosted by Auth0.
For metadata you have a lot of flexibility:
adding “static” metadata as part of the user signup / onboarding process
add metadata dynamically based on data from your own database
skip metadata altogether and just use claims in your tokens
Thank you for the insight and details Mark! We’ve given the API a spin (basic node/react app to test out options) and it seems like a single Auth0 datastore + an internal DB for organization management and the use of app_metadata is the path of least resistance here.
One question that we’re trying to determine if we need to build our own JWT setup for is - the public API. You can think of this like the Google Maps API, or a Weather API - it’s an API that will need to have a public API key, and requests to the API are made via AJAX from users’ browsers, without any user context. But, there is no intermediary server, so Machine to Machine doesn’t fit well here.
Does Auth0 provide any sort of options that could satisfy this use case, or would we have to create our own bearer tokens to handle this portion of the project?
You’ll need to do your own API keys for that part. Auth0 doesn’t offer a generalized API key management service.
I will put in a plug for using your own DB and connecting it as a custom database, vs. using the Auth0 datastore. Make no mistake, I love me some Auth0 and we are super happy with the service where I work, but the Auth0 hosted DB has some significant limitations you need to be aware of:
no backup & restore - Auth0 does their own backups for their own DR purposes, but there is no facility for you to “backup or export your Auth0 database”. You can use the /jobs endpoint to do a kinda-sorta export but it is not what people might think it is. Happy to discuss further as I use the /jobs endpoint all the time.
relatively difficult bulk updates - user profile updates must be applied via the API, and this can introduce some frustration, in part b/c there’s no backup / restore, user query is limited to 1,000 results, and, for good reason, the APIs are rate limited. Bulk user profile changes will be much easier in your own DB.
Also, using your own external DB may make a future migration to another service provider, or integration with some other related service, easier.
On the other hand, using your own DB requires all the usual DIY database stuff, and requires you to map attributes from your DB to Auth0 profile metadata if you want to use metadata. Always tradeoffs and depends on use case of course but, personally I am planning to migrate my data out of Auth0 and into an external data store next year.
Really appreciate your insight. I’m going to further explore utilizing our own internal DB as the store, in that case.
I’ll aim to answer this myself with some digging, but with a proper connection to our internal DB (we’ll be using MongoDB), will all of the Auth0 dashboard user interfaces be available? E.g. to see login history, to modify meta data, reset PWs etc.? Or does some of this go away when migrating out of Auth0?
You’ll still have all of the Auth0 dashboard stuff. What you see in the dashboard is “user profiles” … think of this as a database view, but not your actual database / system of record (Mongo). I don’t know the actual technical details of Auth0’s architecture but I find it useful to think of it this way:
The Auth0 service maintains a “profile database”, which is populated from data received from the system of record (Mongo in your case),
It is this profile database that we see when we look at the users page in the management console, or when we query the mgmt API,
The profile DB also stores the user_metadata and app_metadata objects.
So your system of record, Mongo, stores your user data + credentials. Auth0’s profile DB will store profiles constructed and updated from your system of record. You could also have other systems of record connected at the same time. Social login, other custom databases, enterprise connections … in every case when a user logs in an entry is created in the profile database for them using the data from the source system. Which is why you can some very different looking profiles.
For metadata, which is maintained in the profile database itself, it is up to you whether you want to maintain static data in the profile DB, dynamically push data from your system of record into the profile DB, not use metadata at all, etc. There are many ways to handle this part.