Refreshing JWT with Rules applied after metadata update

JWT.io
1

I’m not sure if I’m just totally missing something but after calling the Management API to update a logged in user’s metadata how can I reissue the JWT?

The returned JSON from the update call is a raw dump of the user and not the rule processed normalized version received after authenticating.

Does it have to be refreshed using an offline_access scope or is there another method I’m missing entirely?

2

Hi @punt.

Are you looking to have updated information in the ID Token issued at the moment that the rule runs? Or are you looking to update the information that applications already received in an ID Token when the user profile is updated from the Management API v2?

When a user authenticates, a snapshot of the user profile is put in the rule’s user object. After the rules run, that object will be used to construct the ID Token (and the results from the /userinfo endpoint) that is available to applications.
If you are updating the user profile in a rule and want to make sure that the ID Token about to be issued contains the updated information, then you should also update that transient user object.

Are you using “custom claims” to pass the app_metadata information in the ID Token? Or are you using the “Legacy user profile” where the metadata object appears fully in the token’s payload?

3

Hey nicolas,

We’re simply calling update via the management API (Auth0 Management API v2)

This returns the raw JSON of the user once complete.

What we’re expecting is for a new JWT to be issued (or a method to resissue one) that contains the updated data, which is manipulated via Rules within Auth0

4

ID Tokens are issued when application requests them. This usually happens when the user first lands in the application, and the application wants to know who the user is to create a session. Depending on the type of application, you can either:

  • use a refresh token flow to request a new token without involving any user input. This works for native apps and regular web applications that can keep the refresh token securely.
  • request a token like you did the first time (a regular /authorize call). This is interactive (it assumes the user is using the application). Depending on whether the user still has a session or not, it might not require the user to enter credentials again.
  • request a token using checkSession in Auth0.js. This attempts a silent token request (no user intervention) and relies on the user still having a session at Auth0. Since it doesn’t use refresh tokens, it is suited to use on SPA.

Where are you calling the management API from to update the user? Is it the same application for which you want to receive an updated token? What type of application is it?

If the management API request was done from the same app that needs refreshed information, the easiest (fastest) path is to just update the session with the new information. If you absolutely need rules to be run, then you’ll need to request a new token. If the management API request was executed because of a user interaction (e.g. “I want to update my last name”) you can simply redirect to the login endpoint of your application so that it triggers the regular login flow. This, as said before, might not require the user to enter credentials again if there’s still a session at Auth0.

1 Like