Signup / first login info

[dpramanik]

Hey, I am using the nextjs-auth0 library to integrate auth0 inside my next application. I have a mongo database behind it. My goal is to ensure that when user signs up (normally/via social logins), I will catch the user id of the user who signs up and store it inside my database. Any suggestions for that ? Is there a way I can get that specific information about the first login / sign up, so I can do the db transactions only at that point. Or is there any other optimal way to handle this ?

Thanks

[dan.woda]

Hi @dpramanik,

There are several ways to go about this.

• You can set up a rule that calls your API and creates a user in your DB. When the call completes successfully, have it add a flag to your user’s app_metadata, stating they have been added to mongo. Have this rule run for any user who is missing the flag.

OR

• Add the user to the database when you get the token. When your next app gets the user’s token, search for their user_id (the sub claim in the token) in mongo, and if you can’t find it then add them to the DB.

There are quite a few threads talking about each approach, I would just hit the search function and you should be able to find some examples of how to implement.

[dpramanik]

Dan thanks for replying. I am going with the second option. But my concern there is, every time I login I don’t want to do a find/create in the database. Only when a user signs up I want to do that transaction. Is there a way to do that ? Any way to send some additional info in the session cookie from where I am retrieving the user id via session.user.sub ?

[dan.woda]

@dpramanik,

You could add a flag to the token to let the backend know the user is/isn’t added to the database, similarly to how I described the first solution, but directly in the app instead of via an API call from a rule.

Sample Use Cases: Scopes and Claims

[dpramanik]

Hey dan thanks for replying. I am using the nextjs-auth0 library. Is there a hook which can set that flag inside the token ? Or any examples for that ? So that after setting that flag next time when I retrieve the session info, the flag is set and I will have the check based on that. Thanks.

[dan.woda]

It sounds like there may be some confusion. Did you look at the docs I linked? Your next app cannot alter the token. That is done in a rule.

[dpramanik]

Yes I did look at the doc you attached, but have some questions on that. As per my understanding, we will need to create a rule that will add a custom claim (for example: is_added) , to the id token, whose default value would be false and once that user is added to that database we will change this claim variable. If this is the way you are talking about, not sure how we will set up the default value and change that later. Another way would be when the user signs up, we will need to to identify that activity within that rule(not sure how we will identify that), and then maybe a set up custom is_sign_up claim whose value would be true. The second way is based on a line from the doc.

When creating your rule, make sure to set some logic that determines when to include additional claims. Injecting custom claims into every ID token that is issued is not ideal.

[dan.woda]

Great, you are on the right track.

@dpramanik

not sure how we will set up the default value and change that later.

Once you have added the user to your database, you would update the user’s app_metadata via the management API, from your backend.

This is why I typically see the other approach that I suggested, where you add the user to the DB if they don’t exist. It doesn’t require flags, rules, or calling the management API. It is much simpler, if the user doesn’t exist, create them.

[dpramanik]

Yeah dan, I have that set up currently where, when a user signs up / login, I am searching our database, to see if that user exists, or else I am creating them. This process is simple but has an additional overhead of running the find query every time the user logs in. Thus, I was looking for any other solution where I can get that signup data easily from somewhere in the session cookie. I will definitely look into the management api approach.

[dan.woda]

Sounds good let us know how it goes.

[dpramanik]

Hey dan, so how we have set this up currently is, whenever user logs in, inside the handleCallback hook, upon userLoaded, we are checking if the user exists or not, and then if needed we are creating the user on our database. With this, we are avoiding the db call that was happening every time the user dashboard page loads. We will keep this, till we face major performance issues. Thanks.

[dan.woda]

Great thanks for the update.