You need to take in consideration that you can use the Auth0 service for user authentication (following OpenID Connect or other protocols, but OIDC is the most commonly used) and for API authorization (following OAuth2).
In user authentication (OIDC) you will in general get an ID Token (always a JWT, because the spec says so) and also possibly an access token that can be used to obtain information about the user identity that just completed the authentication step. This access token when issued only in the scope of OIDC is both consumed and issued by endpoints that are in control of the same entity (your Auth0 tenant) so it can use a token format based on a unique random value (opaque token, currently around 16 characters) that is then used as a lookup in internal database as validation/processing mechanism.
If you then bring API authorization into the mix (aka the
RS256 the access token will have not just your API audience, but also the audience associated with the
/userinfo endpoint which means the access token can actually serve double duty (call your API and the user information endpoint).
- you must not send ID tokens to your API as a method of authorization.
- you must not send access tokens only meant for the
/userinfo endpoint to your API as a method of authorization.
- you should request an access token meant for your own API and use that one instead; if you need more information about the user then the included by default (which is just the user identifier) then you can include additional information in the access token through the means of custom claims.