Hi John, gd,
we are actually experiencing very similar situation - we have an /authorize request in which we do supply the audience in the request parameters, the user gets redirected to login, logs in correctly, authorized service gets the code issued correctly but when it exchanges the code for token, instead of a JWT token it receives an opaque token.
The suggested solution to use a default audience did not solve our issue. Moreover, the issue seems to happen “sometimes” - all our customers are using the same mobile application that has the actual parameters for the authorization request hard-coded inside it. For some customers it works just fine (i.e. they do login and the authorized service then does receive the JWT token correctly), for some we noticed on the authorized service side that we receive an opaque token.
The only thing we were able to find in the Auth0 logs is that for a failed-case (opaque token issued in the end), the login log for the affected user is “details/prompt/name:authorizationless” whereas for the successful case it is "details/prompt/name:“lock-password-authenticate”.
We do have a support case open for this and are trying to figure out what’s the cause. But for the general question - if anyone might have an idea how an authorization request could end in this “authorizationless” flow despite the audience being specified in the request and the default audience for the tenant being defined, it will be highly appreciated.