New API returns short access_token and no id_token by default and breaks Lock

[dinvlad]

Hi all,

My passwordless Lock suddenly stopped working (without any changes on my part) because the new authentication API apparently returns a short access_token and no id_token by default. As a result of that and #130, this change breaks Lock if we rely on the old behavior (incl. using parseHash() and getProfile() that both expect an id_token).

Could this Lock be updated according to the new API?

EDIT: this behavior is happening to a stock configuration of Lock. If we specify audience, the return access_token is "fat" but there's no id_token in either case (and that one is required by parseHash() and getProfile()).

Thanks

[dinvlad]

False alarm, it turns out that I checked strict OIDC conformity in my client settings, which led to this behavior (namely returning only a short access_token when I don't specify an audience)

[hyena]

Is it just me or does the documentation on https://auth0.com/docs/client-auth/current/server-side-web#exchange-the-code-for-an-id_token request strict OIDC conformity and yet the example exchange code for e.g. cUrl doesn't specify an audience and hence doesn't retrieve an id_token?