Based on the information you provided you’re using Lock embedded in the client application itself. If this is the case ensure you’re using a Lock version (10.22+) that supports cross-origin authentication. Be sure to also read the reference documentation for that type of authentication.
In relation to obtaining a JWT access token that will happen when the
audience value you configure in Lock is associated with an API that uses that token format. At this time, any custom API you configure in the APIs section will imply the issuance of a JWT access token, however, in the future other formats may also be supported. Also have in mind that some audiences like the one associated with the
/userinfo endpoint do not make use of JWT access tokens so that could be one explanation for the behavior you experiencing.
As a final note, take in consideration that the client application should not make any assumptions about the access token format and should treat it as an opaque value; it receives the access token and sends it to the API for which the access token was requested. You can indeed use the
expires_in value (which is available in the data object passed to the
hash_parsed event of Lock) to have some notion about the lifetime of the access token, but the client application will still need to handle the possibility of the token being rejected before that time.