Obtain user_metadata from access_token: Not using rules

Help
, ,
1

I am calling /oauth/token API endpoint and getting access_token and other information, but unfortunately, the access_token does not contain user_metadata object. Having user_metadata object is critical for us, as it stores userId from the custom database.
As a workaround, we could use a rule, such as below, to enrich the profile.

  user.user_metadata = user.user_metadata || {};
  var namespace = 'https://example.com/';
  if (context.idToken && user.user_metadata) {
     context.idToken[namespace + 'user_metadata'] = user.user_metadata;
   }

But it comes with namespace prefixed, which adds some complexity in retrieving the userId.

 "https://example.com/user_metadata": {
        "userId": 33,
        "color": "blue"
    }

Question 1: Is it possible to retrieve user_metadata by just adding scope (user_metadata maybe?)?

Question 2: If above is not possible, is it possible not to include namespaces into the rule?

2

I have tried to request profile from /tokeninfo endpoint and it gives the user_metadata information, why is this? And could I use it instead of requesting /userinfo endpoint?

3

From my understanding /tokeninfo is being deprecated, which means it is not safe to use.

4

Some legacy endpoints like /tokeninfo return all available information, including user metadata, this may seem convenient at first, but provides no flexibility for the developer as you have never have any saying in which set of information is returned.

As part of the push to full OpenID Connect compliance and the API Authorization (new) flows the existing possibility of returning the full user metadata by default was removed. Instead and like you mentioned, the recommended approach is for you to be explicit in which custom information you want to include in the issued tokens.

This means that:

  • (Q1) With the new flows (the /oauth/token endpoint being a part of them) it is not possible to have all the user metadata returned by simply including the user_metadata scope.
  • (Q2) All custom information included in the token must be namespaced, so that would be a no.
5

@jmangelo , thanks for the explanation. This complicates things as I have to take the namspace into consideration. The reason I am asking is I use custom-db-provider and store user info in my local database. When I save/request data I include/get userId from the user_metadata object.
Just to make sure, is the user_metadata only object where I could store custom fields?

6

You mention user identifier from metadata and custom databases so I’m assuming you have a different user identifier in your local database and this is currently part of metadata. In this specific situation, one option would have been to return the local user identifier in a way that it would be used as a component of the final Auth0 user identifier. This would mean you could derive the local identifier from the Auth0 identifier, but this would be a good option when starting with a fresh connection.