An ID Token (within the scope of OIDC) will always be a JWT because that’s a requirement of the specification. However, the format of access tokens is left as an implementation detail for the identity provider/authorization server.

Currently, Auth0 may issue either opaque access tokens (relatively short tokens made of a random sequence of characters) or a JWT access token. The JWT access tokens are currently being issued when the request states that it wants to leverage API Authorization (aka audience parameter).

The ID Token will include as part of the claims contained within the token itself the OIDC user information requested during the authentication request. For example, if you include scope=openid+email then the ID Token will contain an email claim if the user has one. This means you may not need an additional request to get user information.

If you’re making an additional request you can call the /userinfo (https://github.com/auth0/lock#getuserinfoaccesstoken-callback) endpoint to get user information; calling this endpoint requires that you provide a suitable access token. This can either be an opaque access token or a JWT access token that lists the /userinfo endpoint as a valid audience.

Have in mind that getUserInfo is different than getProfile (they accept different tokens) and the recommendation is also to move away from getProfile (see the note at: https://github.com/auth0/lock#getprofileidtoken-callback). The error you got with getProfile might have been caused by using the incorrect token with it, but my recommendation would be for you to move to getUserInfo instead.

Finally, take in consideration that the use of Lock with API Authorization (aka audience parameter) is not yet documented so your mileage may vary. If you want API Authorization the currently recommended approach is to use Auth0.js v8, in particular, the methods that make use of the hosted login page.

I’m afraid I can’t provide a definitive timeline; it’s something being worked on, but trying to provide you with more concrete information could just be settings the wrong expectations so at this time there is not a hard date for it.

As mentioned above, at this time Lock embedded within your client application does not yet fully support what you intend to do. However, Auth0.js is supported so if you have issues with that the recommendation would be to post it as a separate question.