After signing up, a user is allowed to log in. Is there a way to detect if this is their first log in ever, so that I can take them to an onboarding flow (like, set up profile, etc)?
Thanks.
Edit: I see this in the dashboard: 
Related?
Hi @simpleauthority,
You can check for logins count in a rule with context.stats.loginsCount. Check out this example:
You can also redirect from a rule for the onboarding flow.
https://auth0.com/docs/rules/guides/redirect
Hope this helps!
Dan
Super cool, thanks! This should work.
@dan.woda Follow up to the rules guidance, can I detect which domain auth0 is about to redirect to? We’re going to have a few apps. The first login to each app should trigger its own onboarding flow.
Would using the client name or client id work sufficiently as a identifier? They are available in the context object:
2 Likes
Thanks for your guidance. Here’s a quick way to implement an onboarding redirect with a rule while maintaining an optional nature:
function (user, context, callback) {
var loginCount = context.stats && context.stats.loginsCount ? context.stats.loginsCount : 0;
var url = context.clientMetadata && context.clientMetadata.onboarding_url ? context.clientMetadata.onboarding_url : undefined;
if (loginCount <= 1 && url) {
context.redirect = { url };
}
return callback(null, user, context);
}
Installing this rule will by default do nothing, until you add a metadata to your app keyed onboarding_url.
@dan.woda Sorry for the pings.
When a user has been redirected from a rule to the
/continueendpoint, the user object won’t be refreshed. So any updates to user account information during the redirect will not be reflected in the user object. For example, metadata updates that occurred during redirect will not be available.
I see this in the redirection docs.
Do I still get the access token from the log in? With my onboarding, I won’t be updating the auth0 user object; I’ll be updating mine. So, in that case, can I effectively ignore having to “continue” authentication?
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.
Thanks,
Dan
1 Like
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?
1 Like
@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.
https://auth0.com/docs/scopes/current/sample-use-cases#add-custom-claims-to-a-token
Ah perfect. Thanks again! This topic should be solved for real this time. 
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.
I would guess that was thinking…but not sure. It has always been odd to me that it starts at undefined instead of zero. 
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