I am playing with a Rule that adds a custom scope to the accessToken. I am using the Authorization Token Flow, and I have noticed that the idToken is not returned from the /oath/token endpoint when this rule runs. The rule is very simple:
This behavior is the same whether or not I pass an API name as audience. I wondered if this might have something to do with the “OIDC Conformant” setting on my Application, but after turning that off, I get the same behavior.
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.
Yeah it’s not just you. I’m using a username password authentication from a highly trusted app. The refresh and id token were working fine. Then I added a rule to add additional scopes and the id token and refresh token quit returning, only the access token.
Ok right after I posted this I realized that I’m replacing the scopes that were requested. So adding the openid and offline_access back into the scope fixed this.
Is there a way to see the scopes that were requested and add them back?
Ahhh! Excellent observation - I have the same question - where can the requested scopes be found? I was trying to preserve them by only assigning context.accessToken.scope if it was undefined, but it seems as those requested scope values ought to be there already.