Refresh_token from passwordless does not return a new id_token

Help
,
1

If I log in using passwordless (deeplinking method), then do a refresh_token, I don’t get a new id_token, but only an access_token. If I log in using email/password, the refresh_token does return a new id_token. Is this by design or is it a bug in passwordless?

This is an example (doc-ed) of the POST that I used for refresh_token:
https://mydomain.auth0.com/oauth/token

Payload:

{ 

       "grant_type": "refresh_token", 
        "client_id": "abcdefgj7L9ae32eaKSZsMBcgLugb4", 
        "refresh_token": "a1234dfgmjuQs9SDkO-zVWO2Imh3ONbU7Xom4Bun7"	
}

Result:

{

      "access_token": "rJxxxrcDzlwrEynM0",
      "expires_in": 86400,
      "token_type": "Bearer"   
      <==== The id_token is missing.
}
2

Based on the information provided you’re performing a refresh token grant at the /oauth/token endpoint. This endpoint is part of the latest and recommended set of authentication endpoints which provide OpenID Connect (OIDC) conformance. However, it provides limited functionality if the refresh token in question was not obtained also through the latest authentication endpoints that also meet the OIDC compliance requirement (aka it was obtained through a legacy method).

To my knowledge, the only currently supported method to do passwordless in an OIDC conformant way would be to perform it through the hosted login page so although I haven’t used passwordless lately and as such my memory is not really fresh on the details you’re likely obtaining a refresh token through what would be considered a legacy method. In this scenario, the way to use it to obtain a refreshed ID token would be to call the delegation endpoint which is also legacy. The ultimate recommendation would be to stay within the boundaries of OIDC conformance, however, if you need additional time to adapt the client application you may want to consider to use a passwordless refresh token against the delegation endpoint as a temporary measure.