"id_token" missing in "/oath/token" response when Rule adds custom scope to "context.accessToken"

Get Help
, , ,
3

Thanks @thijmen96. I tried that and it didn’t quite have the result I was expecting. I’m using the “Authorization Code Flow”, so I’m used to the id_token being returned from the /oath/code endpoint, and the redirect query string having only the authorization code in it (&code=XXX).

Passing response_type=code+id_token causes the id_token to be included in the callback URL query string: code=XXX&id_token=YYYYY (I had to include a nonce=ZZZ query param as well - endpoint returns an error without that). I suppose that does achieve the outcome I’m seeking (actually receive the id_token somehow), it’s just not how I understand the “Authorization Code Flow” to work.

My underlying question, however, is why? Why does simply touching the scope in a rule cause the id_token to be omitted from the response? I played with my rule, just commenting out the part that adds an item to the scope array, leaving the part that initializes the scope as an array, and even just that causes the /oath/token response to omit the id_token.

function(user, context, callback){
  context.accessToken.scope = context.accessToken.scope || [];
  callback(null, user, context);
}

/oath/token response:

{
  "access_token": "<munged>", 
  "token_type": "Bearer", 
  "expires_in": 86400
}

Really scratching my head here.