Currently, an access token issued for your API will be a JWT and include in the
sub claim the user identifier of the user that is associated with the request. The user identifier, uniquely identifier the users and is also a stable piece of information (it does not change unless you bring account linking into the equation).
If you need to only uniquely identify the user associated with the request then the default information available in the token (user identifier) should be sufficient to not require to call the
/userinfo endpoint. Have in mind that you’re not forced to use the Auth0 user identifier everywhere you want a user identifier in your application data store. For example, you can implement a simple mapping between the Auth0 user identifier and an internal identifier in order to have more flexibility.
If you need more information about the end-user then just the user identifier then you’ll either have to include that information in the access token or query it when you’re processing the token. The two approaches are not equivalent and both have their pros and cons, for example, including it in the access token will mean the information will not change during the lifetime of the access token, however, querying it upon receiving the access token introduces overhead and you would also have to be considerate of rate limits in the endpoints you would be querying.
In conclusion, the ultimate decision will need to be done by you in light of your specific requirements, however, I would personally tend to favor including the information in the access token itself as long as it’s not a substantial amount of information and it’s also information unlikely to change very frequently.