Hi,
I’m trying do understand if using auth0 as a user profile canonical store is considered a good practice.
Basically I would like to use user_metadata to store user information like uni they attended, address, email, interests, etc.
Thanks
Hi @duartegarin! Welcome back.
Take a look at this article. It addresses the issue and should help you make an informed decision:
Let me know if you have further questions,
Dan
Hi Dan,
I did read this but confess I’m not 100% clear.
Auth0 states in some docs that if the data is “identity” related it belongs in user metadata (and it is in my case). However in others it states if its “needed for authentication” it belongs in user metadata (and in this case it’s not, for example I don’t need the university the user attended for him/her to login).
Ideally we want to use Auth0, as an additional store complicates things from an architecture point of view.
Can you clarify that? Thanks again!
The answer here is going to depend on the needs of your application and is likely a tradeoff between robustness and convenience. Yes, you can store data in user_metadata or app_metadata that is not specifically necessary for authentication. As this doc demonstrates, a piece of metadata like ‘hobby’ is not required for a successful authentication, but can provide useful insight on a user.
With that being said, storing a copy of the data in your own database will provide for a more robust and flexible solution. Particularly, I would imagine, with regards to querying the data as a whole set or managing that data. Keep in mind that the Management APIv2 is rate limited.
Let me know if this clears things up,
Dan
Hi Dan,
Thank you again for the clarification. Our use case is a centralised content management system powering many react frontend applications.
I think robustness would definitely be ideal. Just to see if I understand correctly, are you saying that auth0 would be the canonical user store and that we keep copies of the user data somewhere on our side (e.g a relational db?). When you say managing the data and querying, obviously users need to update their profiles, would that be done against auth0 first or our database?
When you say the API is rate limited, do you mean that there is a real scenario where users can’t update their profiles (which I imagine would be an API call under the hood) because the limit was achieved?
Finally, does Auth0 have any documentation on what this best practice architecture would look like (the ideal workflow etc). We are in the process of determining the architecture for our users (and if auth0 is the best fit) and that insight would be extremely helpful.
Thank you again for your assistance, much appreciated.
Duarte
Thanks for the additional questions. Some of the answers to them are going to just depend on how you prefer to architect your application. There may not be one right answer here, but rather different configurations you can decide on.
The user data storage best practices doc I linked above provides some insight on how the process could work, and what data goes where. If you were to use the Auth0 database as just your email/password table, you could receive a userID after a successful login and run it against your own database where more substantial user data was stored. On the other hand, you have the option to store user profile data, and that is certainly an approach some customers take. It is really going to depend on the size/scope of your user data.
In regards to the Management API rate limits; its not that your user would not be able to update information, but rather that you would have to handle a rate limit error if that were to occur. There are strategies for dealing with rate limits as most APIs are going to have some sort of limit. With that being said, the limits are rarely reached under normal circumstance, and are more likely exceeded because of a bug or unintended set of actions.
For the best practices, there are some basic example projects in the docs, which you have likely already run into. They may not cover every possible use case. This is something we are constantly improving, but due to the wide variability in the uses and architectures of the applications that use Auth0, there is no one perfect solution for a complex build. You will have to make some decisions based on what you think will work best for you.
Hope this helps,
Dan
1 Like
Thank you very much Dan.
That helps a lot.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.