There are a couple of things worth mentioning, the most relevant is that the output you showed is consistent with an access token using the JWT format. You’re using an audience value of https://nepherius.eu.auth0.com/api/v2/ which is associated with the Auth0 Management API v2 and at this time the access tokens issued for that API are indeed JWT’s.
However, the user information claims requested through OIDC scopes like profile and email are included, if available, in the ID token; not in the access token. In addition, the client application should treat the access token as an opaque value and not do any assumptions on its format. The only thing the client applications does with the access token is to send it to the API(s) to which the token is applicable to.
In conclusion, you should be outputting the contents of the ID token which is guaranteed, by specification, to always be a JWT and then if you still don’t see the information requested we’ll need at other possible issues.
Also have in mind that the use of the Auth0 Management API v2 identifier as an audience is a bit unexpected and that including identities as one of the scope values will have no effect because that’s not a scope value contemplated in the OIDC specification and as such it could only have some effect if the API specified in the audience value did specify it; which is not the case.