How to implement Auth0 in a database

Help
1

Greetings,

I’m new to the whole concept of an IDAAS. I hope someone can help me understand how Auth0 works in conjunction with a database.

I know that Auth0 doesn’t recommend storing non-profile user data on its service. Does that mean that in my database, there should be an id field that’s the auth0 user id? Would I need to write another script to sync the creation / deletion of auth0 users with their respective data in my database?

Or is there a simpler better alternative to the above solution?

Update: I found this discussion from someone with a similar question. If I’m understanding it correctly, for the purposes of a Twitter-like application, you can’t go wrong with:

  1. Storing only user authentication data with Auth0
  2. Storing all other user data in your database
  3. Joining your user data with Auth0 through the ids provided upon login

With this approach, most of your data will be in sync. The only case you’d have to take care of is the creation or deletion of users in Auth0, which can trigger a corresponding create/delete of user data on your database.

5 Likes
2

Hi @fandy.
Indeed, Auth0 will return a user ID that is guaranteed to be unique and also to be the same every time the user authenticates with the same method. So you’d use that ID to fetch the relevant business data from your application database.
Whether you need to sync data or not would depend on your business requirements. Auth0 will provide the most current user information every time the user authenticates, but if you need historical data (e.g. previous email addresses or names a user might have had) you’ll need to store them on your app.
As for any records that represent a user on the application side, you can always defer the creation of those until needed. E.g. when Auth0 returns a user ID that you’ve never seen before (no records in your DB), that would be a sign that the user is here for the first time, and you can use the opportunity to create a welcome experience, maybe ask some additional data, and create a record on the database.
Hope that makes sense!

4 Likes
3

Thanks @nicolas_sabena for clarifying for me. Your explanation makes sense.

Should I make sure the user ID is never exposed, then? Is there a best practice for encrypting it or keeping the API access secure?

4

I guess the answer depends on the type of application you have. The user ID is visible in access tokens and ID tokens issued by Auth0.If your application is a SPA with no backend except for an API, you’d have no choice because the app will need access to the access token to make requests to the API. So a legitimate user would be able to see his ID and access token with little effort. If you are doing a SPA a typical precaution is to set a short expiration time for tokens so that if someone else uses the browser the token would no longer be valid. But someone could decode the token and see the user ID easily.

2 Likes
5

Following up to this design paradigm — what is the right way to “create” a user in my backend?

User registers for an account using Auth0. My frontend gets the ID token — does it make a special API call to my backend to add this user with the sub ID?

I would have thought a robust (retries until an ack is received) webhook from Auth0 to my backend would work best, but not finding this solution.

Thoughts?

2 Likes
6

Hi @nelsonian , did you figure out a solution to this – I can’t work out a robust way of managing this and it seems so necessary as surely people aren’t going to Auth0 via the REST API for user reads?

e.g. Imagine trying to resolve an API request like this:

query Orders {
   orders(first: 500) { # db.orders.findMany(500)
      id
      user { # auth0.getUser(order.userId) (* 500)
         id
         email
         firstName
         lastName
      }
   } 
 }

If the users were in your own DB you’d obviously do a join on orders → users, but if having to go to Auth0 you’d be performing 500 API calls in parallel (presumably hitting API rate limits) – there doesn’t appear to be any batch endpoints?

1 Like