There are a couple of things worth pointing out, in particular, you can add custom namespaced claims both to the ID token and access token (as long as the access token is being issued as part of an API authorization flow to your own API, so that it is issued as a JWT access token). The ID tokens are always a JWT according to the specification so as long as you are using OIDC compliant authentication the custom namespaced claim added to the ID token will be included in the token and also returned as part of a call to /userinfo.
As you may have noticed I highlighted the word namespaced when mentioning custom claims because they indeed need to have a namespace, because if they don’t have a namespace or they use one of the restricted namespaces they will end up not being included in the issued token; see the reference documentation for more information.
In relation to scope this modification is only applicable to access tokens.
Finally, I could not reproduce the issue with the following sample rule:
function (user, context, callback) {
var namespace = "https://example.com";
context.idToken[namespace + "/reference"] = "X0T3F";
context.accessToken[namespace + "/reference"] = "X0T3F";
callback(null, user, context);
}
After completing the authentication/authorization through:
https://[tenant].auth0.com/authorize?client_id=[client_id]&redirect_uri=[redirect_uri]&state=qIgR1RHOA&response_type=code&scope=openid+read:examples&audience=[audience]
resulted in having an ID token containing:
{
"https://example.com/reference": "X0T3F",
"iss": "https://[tenant].auth0.com/",
"sub": "[user_id]",
"aud": "[client_id]",
"iat": 1504537305,
"exp": 1504573305
}
and an access token:
{
"https://example.com/reference": "X0T3F",
"iss": "https://[tenant].auth0.com/",
"sub": "[user_id]",
"aud":
"[audience]"
],
"iat": 1504537305,
"exp": 1504623705,
"azp": "[client_id]",
"scope": "openid read:examples"
}
In this scenario, have in mind that both the ID token and access tokens will be JWT so you’ll need to validate them and decode them before being to access the data in question. The ID token is meant to be validated/consumed by the client application, while the access token is meant to be validated/consumed by the associated API/audience.
Finally, I would advise making your tests with a simple rule like the following and then move to rules that actually meet your requirements, including adding conditional logic and other feature as that will allow you to trace the root issue of the problem. More specifically, if the rule is so simple and you still have issues then the possible source of the issue is less than it would be with complex rules.