<div dir="ltr">You still get an id_token with these _hash values (albeit optionally) from the token endpoint issued id_token, the client MAY still validate it if it's present.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>- When using the Hybrid Flow, the Access Token returned from the Token Endpoint is validated in the same manner as for the Authorization Code Flow.  </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- When using the Authorization Code Flow, if the ID Token contains an at_hash Claim, the Client MAY use it to validate the Access Token in the same manner as for the Implicit Flow, as defined in Section 3.2.2.9, but using the ID Token and Access Token returned from the Token Endpoint.</blockquote><div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Best,<br><b>Filip Skokan</b></div></div>
<br><div class="gmail_quote">On Fri, Dec 9, 2016 at 11:42 AM, Roland Hedberg <span dir="ltr"><<a href="mailto:roland@catalogix.se" target="_blank">roland@catalogix.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span class="gmail-"><div>On 8 Dec 2016, at 17:15, Filip <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.com</a>> wrote:</div><br class="gmail-m_749091023977178106Apple-interchange-newline"></span><span class="gmail-"><div><div dir="ltr"><div>Hello,</div><div><br></div><div>While testing for all specified test/profiles in the PDF i've encountered the following five issues for these test + response_type combinations<br></div><div><ol><li>id_token/rp-id_token-bad-at_<wbr>hash<br></li><ul><li>is listed in the PDF for implicit profile, test description clearly only mentions access_token issuing response types, this test should not be listed in the PDF under implicit-id_token, since no at_hash check will be performed without access_token being present<br></li></ul></ol></div></div></div></span></blockquote><br><blockquote type="cite"><div><div dir="ltr"><div><ol start="2"><li>code+id_token/rp-id_token-bad-<wbr>at_hash<br></li><ol><li>authentication request is failing when response_type=code+id_token, Response {"error_description": "Wrong response_type", "error": "incorrect_behavior”}<br></li></ol></ol></div></div></div></blockquote>You get at_hash'es in the id_token when an access token is return in the same response. If you have response_type=code+id_token</div><div>there is no access token returned hence no at_hash. Hence, it makes no sense running this combination.<br><blockquote type="cite"><div><div dir="ltr"><div><ol start="3"><li>code+token/rp-id_token-bad-at_<wbr>hash<br></li><ol><li>authentication request is failing when response_type=code+id_token, Response {"error_description": "Wrong response_type", "error": "incorrect_behavior”}<br></li></ol></ol></div></div></div></blockquote>Sort of the same, if you don’t get back an id_token (which you don’t with response_type=code+token) where would the at_hash appear ?<br><blockquote type="cite"><div><div dir="ltr"><div><ol start="4"><li>code+token/rp-id_token-bad-c_<wbr>hash</li><ol><li>authentication request is failing when response_type=code+id_token, Response {"error_description": "Wrong response_type", "error": "incorrect_behavior”}<br></li></ol></ol></div></div></div></blockquote>Same as previous but about c_hash instead of at_hash..<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="gmail-HOEnZb"><font color="#888888"><br><div>— Roland</div></font></span></div></blockquote></div><br></div></div></div>