<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 31. aug. 2011, at 19:22, Breno de Medeiros wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">The check session endpoint MUST validate browser session matches the id_token.</span></blockquote></div><br><div>I probably did not explain my point very well. Let me try again.</div><div><br></div><div>This does not even need to include the check session endpoint to perform the attack.</div><div><br></div><div>The issue I'm referring to is the combination of leaking ID Token to the browser history log </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(something that could happen with the check session request)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>and</div><div>accepting a new ID Token as an incoming front-channel request.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(something that is done with the check session response)</div><div><br></div><div>The attacker would first need to obtain a ID Token for a another user, then establish a session at the RP as him self, and then make the RP issue a check session request. The reason that it needs it to generate a check session request is that the RP then presents a state; which makes it easy for the attacker to craft a valid response (without being in contact with the check session endpoint) by combing this state parameter with the id token jwt found in the browser cache.</div><div><br></div><div>This attack would not be possible if the RP did a comparison of the user_id in the check session request and the response.</div><div><br></div><div>And BTW; if "The check session endpoint MUST validate browser session matches the id_token."</div><div>you should add that the to spec. In addition you have to explain what it mean to validate a browser session against an id_token. As there is no session identifiers involved in openid connect, I must admit it is not totally clear to me how that can be done. Should in example the provider cache all issued ID Tokens (or hashes of them)? Or is the session concept intensionally dropped, and comparing the user_id and authentication level is sufficient for comparing a ID Token with a 'browser session'.</div><div><br></div><div>Andreas</div><div><br></div></body></html>