I have Auth0 implemented in my Angular JS 1.5 app and it is working for my Google users and my userid/password users. When the user logs in, I have a rule that adds their custom claims to their id token, and then in my angularjs app, I can look at those claims and act upon the custom claims.
My issue is when a new user signs up, either with Google or a username and password, the id token does not have any of their custom claims and the profile is missing the app_metadata.
If the user logs out and logs back in, the profile and the id token are correct. Can I get this information after a signup in my angular js application?
The information provided is insufficient to provide definitive answers, but going with what’s available I was not able to reproduce the situation.
In particular, you mention app_metadata which upon signup through the public endpoints cannot be provided so I’m assuming that you’re also populating the initial values through a rule and then you’re setting those initial values as custom claims in the ID token.
I used the following rules and signing up database connections users through the hosted login page (Lock) worked as expected and the custom claim was included even at first login:
// first rule to run initializes app_metadata
function (user, context, callback) {
user.app_metadata = user.app_metadata || {};
if (user.app_metadata.reference) return callback(null, user, context);
user.app_metadata.reference = "XYZ";
auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
.then(function() { callback(null, user, context); })
.catch(callback);
}
// second rule to run adds the custom claim to the ID token
function (user, context, callback) {
var namespace = 'https://example.com/';
context.idToken[namespace + 'ref'] = user.app_metadata.reference;
callback(null, user, context);
}
I would recommend trying something above and be sure to have the second rule shown execute after the first otherwise you’ll get an error because metadata is initialized only by the other rule. If you still have issues then you need to update your question with more information, including the rule code you’re using.
First, I had two rules and there were almost exactly like yours, I followed the tutorial.
But, my problem, as you mentioned is the two rules in the wrong order. So, it was adding the empty claims and then assigning the default role. Once I reversed them, everything worked perfectly, as I had expected.
We are using the Lock v11 and we have setup a rule to add custom claim: context.accessToken[namespace + ‘accountId’] = user.identities[0].user_id.
However for email + password user signups, accessToken received in the response URL doesn’t contain the custom claims anymore. Logging the context in the rule shows that context.accessToken does have the custom claims added before callback
Namespace is OIDC compliant and on Social Media Signup / Login the custom claims are being returned in the accessToken.