Best Practice for storing User Profile attributes

Help
, ,
1

Hello, I have gone through the react quickstart guide and have a good understanding of the concepts for id token, access token, user_metadata and app_metadata. My question though relates specifically to what and where the best way is to store User Profile attributes if they are need in our application logic. I would like to use Auth0 as the canonical data store for the entire users object, and just keep a local reference to a “user_id” in our local postgres database.

Here is an example, let’s say that we have the concept of Users, and they will have attributes such as: Profile Image, Full Name, email, username (unique), country, and timezone. Users are able to create games, let’s just say a game has a title attribute for now.

Users can search for games and the UI will display a results grid of the games with the following columns: game title, Profile Image, User Full name, country, timezone.

How does my server API generate the response in a performant way to collect the users info needed for each game object? The only way I can think of doing it is with a local “shadow” users table that I have to keep in postgres. That would mean I think would need Rules and an API to keep the profile attributes in sync between Auth0 and the pg users table. If I then think about that more I begin to ask why store the profile information in Auth0 at all at that point?

What is the best practice for handling this use case. It seems like it would be fairly common but I can’t seem to find any logical answers. This post talks about using a local users table with two-way user_id links between the local table and the Auth0 users table. That makes sense to me for the user_id, but what about all the other profile attributes?

3 Likes
2

User profile attributes should be stored in user_metadata. Best practices for using user data storage are outlined here.

You can retrieve the user info using the Auth0 Management API’s Get a User endpoint.

1 Like
3

Thanks for the reply. I know that the best practice is the store the user attributes in the user_metadata field (or app_metadata). My question though is what if I need those attributes in my application. I know I can make an API call to get the metadata for a single user, but that solution does not scale.

For example, what if I want to return a list of 25 “games” and with each game display some fields from the user profile. I am not going to make 25 API calls to Auth0 /userInfo API first. That will introduce too much latency in my API response for the “games”.

4

I’m not getting why you are gonna make 25 API calls. Just make a single API call and use the attributes in the list before displaying.

5

Does the Auth0 userInfo API allow you to get user_metadata data for multiple users in a single call?
Otherwise I would have to make an API call for userInfo for each user for each game to be returned. This example assumes that there is a different user that owns each game in the list.

6

If that’s the case then you can make use of List or Search Users endpoint to get a list of users in a single call.

7

Thanks @prakharkumar79. I reviewed that API and I see I will be able to get a lists of Users with the user_metadata I would need in a single call to Auth0. So that is a pretty good start.

That still begs the question though that I don’t want to be making an API call to Auth0 for every request to our system. These double API calls add too much latency and time to the application response. If you can imagine most objects within our application will need to display at least some level of User information (ie. even a name and profile image, etc).

I can’t believe this use case doesn’t come up more often. Surely any application that uses Auth0 will have its own level of application logic and data objects that need to exist within the application but depend to some level on User data.

I am basically asking about this example from the Auth0 docs, but instead of returning the user’s own “favorite music”, the user instead wants to look at some other “combined music list” with favorite music from several users.

8

API call is the only way to get the user info. If you will go for storing the user info in the DB then you have to suffer from DB hits which will have the same effect as calling the API if your DB is not locally stored.