Auth0 Home Blog Docs

Read custom claims in Angular



I’m having a bit of trouble understanding how claims work.

From what I understand, I can add custom claims and scopes to both the Access Token and the ID Token using rules or Hooks. I’ve done so, and it works fine, when I console.log in the rule everything is there.

What I don’t understand is how I should read those claims from my Angular2 application.
If I print the token, I get a string. If I print the user profile, I just get the user info, but not my custom added claims. I’ve already tried with both access and ID tokens, and my custom added claims don’t show up.

P.S.: I’m using the auth0-js, and I followed the Angular2 quickstart to create my app, if that helps.

How can I get user's role when this user logged in

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 = "";

  context.idToken[namespace + "/reference"] = "X0T3F";
  context.accessToken[namespace + "/reference"] = "X0T3F";
  callback(null, user, context);

After completing the authentication/authorization through:


resulted in having an ID token containing:

  "": "X0T3F",
  "iss": "https://[tenant]",
  "sub": "[user_id]",
  "aud": "[client_id]",
  "iat": 1504537305,
  "exp": 1504573305

and an access token:

  "": "X0T3F",
  "iss": "https://[tenant]",
  "sub": "[user_id]",
  "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.


Thank you very much, I understand how it works now.
Everything working correctly.