Redirect to onboarding flow after sign up (or first log in)?

No problem, that’s why we are here!

This is referring to the user object in rules. It looks like the object gets cached and any changes you made to the profile, via the management api for example, would not have updated the object in rules.

After all the rules are run and don’t throw an error.

You need to continue authentication. The redirect functions as a part of the authentication event, and will need to be completed to get the token. It is essentially baking in your onboarding to authentication, making it required or the login fails (no token).

Does that make sense? Let me know if I am misunderstanding something.


You need to continue authentication. The redirect functions as a part of the authentication event , and will need to be completed to get the token. It is essentially baking in your onboarding to authentication, making it required or the login fails (no token).

I see. I can understand how this would be useful but in my case it may not work. Basically, I want their first log in to work like a normal log in – I want the access token to parse and all, but I want a user’s first log in to make it to an onboarding page. I need the access token, because onboarding will call my API which is protected by Auth0.

Is there any way I can do this?

Or, I suppose, I can collect all the onboarding info into some saved object, maybe put it in local storage (? :D), then continue auth and check the local storage later?

@dan.woda Is there a way to get extra info encoded in the JWT (using a rule), such as the login count? If so, then I can do this all frontend and not make auth0 worry about it.

This is exactly what I thought after your first response. If you don’t need it to be part of the auth event then just handle it in the frontend.

You can use context.stats.loginsCount in rules to see how many logins the user has (or undefined). And you can add that number (or just a first login flag) to the token using a custom claim. You may need to write out some conditional logic. Let me know if you run into anything else.

Ah perfect. Thanks again! This topic should be solved for real this time. :slight_smile:

1 Like

@dan.woda Actually, one last follow up to that. When and why might loginsCount be undefined? I am assuming just during the time between when they signed up and when they logged in for the first time.

Can I expect that stats is already initialized, or do I need to check that? If in a rule, if loginsCount is undefined is it okay to set it to 1 and assume this is the user’s first login?

1 Like


It is going to be undefined on first login. You can see how it is handled in the example I posted:

var count = context.stats && context.stats.loginsCount ? context.stats.loginsCount : 0;

@dan.woda Right. But the question is, if it is undefined instead of setting it to 0 by default can it be 1?

It seems to me right now that at first log in it will be 0 (because it’s undefined). Well, what is it at second login? 1, or 2?

It just feels a bit wonky setting to to zero and checking that the count is <=1. I would feel more comfortable if I was checking with a stricter range (say, ==1).

Let me know if that makes sense.

It should function like this; on first login the count is undefined, on second login the count is 1, and so on. I guess it is indicating how many logins previous to the current one.

I can’t speak to why it was set up this way.

Oh, okay. I see. So it’s 0-indexed. Alright, then. I’ll roll with it. Thanks @dan.woda!

I would guess that was thinking…but not sure. It has always been odd to me that it starts at undefined instead of zero. :man_shrugging:

I suppose it does make sense if auth0 rules are somewhat akin to middleware instead of pre- or post-filters.

But all is well now. I understand.

Could I recommend adding that it starts at undefined and increments from there to the Context docs? Just in the name of documenting its intended values.

1 Like

Absolutely! I will pass that along to the team. This kind of feedback is really helpful, so thanks!

1 Like

@dan.woda Maybe not? :smiley:

Just fixed my rule to this:

function (user, context, callback) {
    var request = require("request");
    var count = context.stats && context.stats.loginsCount ? context.stats.loginsCount : 0;
    // Debug
    console.log(`${context.request.ip} signing in, lc=${count}`);
    // Add log in count to JWT
    context.accessToken['https://<namespace>/loginCount'] = count;
    // Exit fast if not first login
    if (count > 0) {
      return callback(null, user, context);
     * Add default role to new users on first log in
    var headers = {
        'Authorization': 'Bearer ' + auth0.accessToken,
    const data = {
        "roles": [
        url: `https://${auth0.domain}/api/v2/users/${user.user_id}/roles`,
        headers: headers,
        json: data
    }, (err, response, body) => {
        return callback(new Error("Can not update users with role"));

    callback(null, user, context);

I also installed real time logs for the debug line near the top:

12:04:55 PM: new webtask request
12:04:55 PM: XXX.XXX.XXX.XXX signing in, lc=1
12:04:55 PM: finished webtask request

I used a brand new user. I don’t have verification required before log in – sign up logs the user in.

Regardless, it was not 0 at first log in; it was 1. I’ll need to figure out which one it is and when (maybe it’s 0 when email verification is required? I’ll check.)

EDIT: Nevermind. I forgot that requiring email verification is a rules-based task with auth0. I don’t think that will change much.

I just tested it and am also getting 1 on a new signup first login. I am trying to think of the edge case where it would be zero/undefined…but yes, it looks like it is 1 on a typical first login.

Hmm okay. Well, if it is a really infrequent case where it’s undefined then setting to 1 if it is undefined vs setting it to 0 should be completely fine, right?

That makes sense to me.

1 Like

Thanks for all your help! Really appreciate it.

1 Like

No problem! Thanks for jumping in on other topics and being an active user. We appreciate all the help we can get. Cheers.

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.