Retrieving user profile -- Access_token used but not id_token?

Help
, , , ,
1

I am in the process of integrating user_metadata into the authentication result returned following authentication. It’s unclear how access_token and user_token are differentiated within rules - it seems claims are able to be added to both, but only access_tokens can be decoded by Auth0.js?

I’m following the Auth0 ReactJS quickstart tutorial uses the access_token returned from auth0 to retrieve user profile information like so:

  getProfile(cb) {
    let accessToken = this.getAccessToken();
    this.auth0.client.userInfo(accessToken, (err, profile) => {
      if (profile) {
        this.userProfile = profile;
      }
      cb(err, profile);
    });
  }

This confuses me because according to Auth0’s documentation, ID_Token should be the mechanism encoding user profile information and not the access_token: auth0.com/docs/tokens/id-token:

The ID token, usually referred to in
our docs as id_token… contains user
profile information (like the user’s
name, email, and so forth),
represented in the form of claims.

Why isn’t there just an extension method of the Auth object that decodes user_id for this purpose?

Should I use the Node.js library listed on https://jwt.io/ to decode the id_token returned by Auth0 instead of following the flow in the quick start tutorial that uses access_token?

In the flow that the quick start documents send me down what is the purpose of the id_token? It seems that only access_token is relevant.

2

After some more digging it appears that I can use the Auth0.js version 8 to create a reference to the management API that I then can use to invoke getUsers using the userId returned from a previous call to client.userInfo.

Is this the correct path to retrieve user_metadata using a id_token? it seems so but…

auth0 allows a way to add this user_metadata directly to the access_code by using rules and this would absolve the need for a subsequent call to the ManagementAPI and getUser if I load the user_metadata into the access_token instead of the id_token –

but a sanity check please – why does auth0 support loading profile information into the access_token?? Isn’t this at odds with the intention of the spec where id_token should contain user authentication information aka user_metadata and access_token should just be used for authorization against an api?