The short answer would be that if you update the scope
parameter to specify openid email profile
instead of just email profile
then you should receive a response containing an id_token
parameter that would indeed be a signed JWT.
The long answer is that there are a few things to consider:
- the
/login
endpoint should not be called directly; instead, call the /authorize endpoint (some parameter names would need to be changed). - the current authentication API can be called in two modes, one that strictly complies to the OpenID Connect specification and the other that predates the final version of that specification and as such as some differences to what’s specified
- In OIDC mode (see OIDC-conformant authentication adoption guide for more information) you would have to specify a
response_type
that would includeid_token
in addition to thescope
that includesopenid
. - In non-OIDC mode a response type of just
token
will also include an ID token in the response in addition to the access token if you specify theopenid
scope.
Also note that an ID token will always be a JWT because that’s how it is specified, while an access token can assume different format depending on the intended usage of the access token.
Additionally, if you’re starting out with the integration with Auth0, the recommended approach would be to make use of the OIDC mode of operation.