I’m currently tasked with migrating our entire auth flow away from our legacy implementation we maintain ourselves.
After doing a bit of research and getting started, I believe I have a overview of how this would work. However, as someone with very limited auth0 – frankly authentication/authorization altogether – experience, I’d much appreciate any feedback on my idea.
Architecture:
React SPA utilizing redux for data flow, mostly interacting with a Flask API that mostly CRUDs into a postgres database
Problem:
Both the SPA and the API rely on a lot of user attributes like is_admin, credit_amount, disciplines, etc, none of which are important to define other than that these attributes sometimes determine which or how components are displayed and other times determine what the API does. All of this data is stored in our internal postgres database in a User table which gets loaded into a Redux store after login.
Goal:
Move authentication and hopefully authorization into auth0. Playing with auth0-react for the SPA right now
My idea of a solution:
Frontend:
Enable automatic user migrations
On new user registrations, add a post registration hook to populate our database with new user
Add a rule on login, enrich the user response with these sort attributes from our database using context.idToken['namespace' + 'attr'] pattern seen in this github issue
Remove all my redux stuff for the user and instead use the useAuth0 hook to get the user w/ these attributes and parse the attributes out with the same interface as the current redux user is accessed, then the SPA should be happy.
Backend:
Relatively simple, add api protection using the setup shown in this documentation but still have access to the user in our database should specific business logic rely on attributes mentioned earlier.
Does this seem like a viable solution or am I completely mis-using auth0 ? Likely somewhere in between, I’d gather. It feels to me, as a developer, like it could work but it’s not the “right” way to do this:
Having to maintain the user in both our database (we also use an ORM so there too) and auth0 seems clunky.
Keeping the two in sync will likely be cumbersome and have scaling issues.
Having to pass up the attributes with the idToken pattern seems weird (I don’t understand why they have to be prefixed by a URI namespace, specifically)
Sorry it’s a longer read, but thanks for taking the time to do so and for the guidance!
You are right. Your solution implies having to maintain and sync both databases. Can I ask why you want to have two databases? Why not either use Auth0 or your PostgreSQL database?
If you don’t want to just use an Auth0 database (which could be accomplished seamlessly via Automatic Migrations) and this is a workaround to avoid using Custom Databases, yes, it’s a weak/not ideal workaround. My recommendation would be to use a Custom Database instead. The caveat is that this is an Enterprise plan feature.
Regarding your last question, you must use a namespace to keep your custom claims from colliding with any reserved claims or claims from other resources. To learn more about this topic, please take a look at Create Custom Claims
I don’t necessarily want to have two databases, I just think it’s going to be necessary due to the many business logic-specific columns we have currently in our user table. For example, we have a column called disciplines that holds a user’s specified disciplines (Plumbing, HVAC, etc) and is used for both displaying and querying purposes. We also have the same user table linked to many other tables in the database as foreign keys, e.g. created_by_user_id
While the former type of attributes might be able to be migrated out as part of user_metadata I don’t think, for the latter, there’s much we can do about – unless I’m missing something, which is entirely possible haha. Given this, does it sound like my solution is sensible to you?
I have read about Automatic migrations and am currently using it, and it seems to have worked; I was able to login to auth0 using a user in my database. Regarding custom databases, here’s where I’m also confused:
To use Automatic Migrations, I have to toggle Import Users to Auth0 on in my dashboard, easy enough.
Additionally, I have to turn on Use my own database under Custom Database
Finally, I have to write the Login and Get User script for auth0 to help in migrations to auth0.
Given that Custom Database is an Enterprise feature, does that mean Automatic Migrations is also an Enterprise feature – since I can’t do one without the other ?
I don’t think you are missing anything, but I think the following article might clarify some things for you: Define and Maintain Custom User Data
Regarding the optimal architecture, it’s really up to you. It’s not easy to give good recommendations over a forum like this, but there are some good discussions here in our Community that could provide some insight for anybody interested in this topic:
Now, regarding your last question about Automatic Migrations, I do know it can be confusing. The explanation is that Automatic Migrations/Database Migration is a feature that depends on the Custom Database feature. By using Automatic Migrations, you are enabling a required sub-set of features (such as Login and Get User scripts) from Custom Databases but you don’t need an Enterprise plan for Automatic Migrations. You can use it with any paid subscription as documented on Pricing - Auth0. I will attach a screenshot below for a better understanding:
Hi @Ale, sorry for taking a bit to respond back to this. With your suggestion in mind, I also reached out to ticketed support. They were not able to give me more than what you gave me though they did forward me to Professional Services. Alas, that’s only available for Enterprise users, which we are not ready to commit to at this time. I think I will just go with my idea for now as it seems the most pragmatic way for us to move forward.
