Why does patchUserMetadata require userId?

Help
1

I’m a little confused with the documentation for using the limited Management API methods from the client side (not a highly trusted backend).

I’ve been able to use patchUserMetadata() with the following:

var auth0 = new auth0.Management({
  domain: "{YOUR_AUTH0_DOMAIN}",
  token: "{THE_ID_TOKEN}"
});
auth0.patchUserMetadata(user_id, {test: "Worked!"});

I’m not sure why the documentation suggests here to use {YOUR_AUTH0_API_TOKEN}as the token when initializing auth0.Management as that would only be possible on a highly trusted backend…?

My question is as follows: Why is it necessary to pass user_id to patchUserMetadata when the PATCH request already includes the id_token which presumably includes the user_id already?

2

Based on the information provided I get the impression that you’re starting the implementation of a new application or at least significantly changing an old one so my recommendation would be for you to not take a dependency on that ID token ability to call management API for very specific user operations.

You can request an access token for Management API if you specify the respective audience; it’s likely that you already are specifying an audience value so you may need to perform a second authorization request specific to the Management API; this authorization request can request a scope like update:current_user_metadata which would then allow you to update the user metadata from the client-side. Have in mind that by default an authorization request for the Management API as part of an end-user flow will trigger the consent screen so if you want to bypass that you’ll need to enable the Allow Skipping User Consent in the Management API settings. Skipping consent could mean that the second authorization request could even be done in the background and leverage the existing session so that this is transparent for the end-user.

With regards to always having to pass the user identifier it’s an implementation choice, it could be argued that if the token is always associated to an end-user that could be optional, but it does not seem to be a big issue.