
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I think you are referring to XSRF protection for the Refresh Session endpoint.<div><br></div><div>Check Session is a direct POST from the client to the Check Session endpoint, for a web server client that would not go through the browser.</div><div><br></div><div>John <br><div><div>On 2011-08-31, at 8:51 AM, Andreas Åkre Solberg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><i>I'm referring to OpenID Connect Session Management 1.0 - draft 03.</i><div><i><a href="http://openid.net/specs/openid-connect-session-1_0.html">http://openid.net/specs/openid-connect-session-1_0.html</a></i></div><div><br></div><div>If we consider is a user agent that logs query string parameters in history (In example Safari does).</div><div><br></div><div>Say that user A logs out of service X, and the service ends the session at the provider as well, this means that the ID Token of the terminated session may be present in the browser history (depending of whether the logout flow includes redirects or displays a info page…).</div><div><br></div><div>Say that user B logs in to service X right after, waits for the session to time out, or force the check session request by other means, and the user is redirected to the provider check session endpoint. Now user B crafts the response to this request, putting in the ID Token from user A (that is still valid!).</div><div><br></div><div>Now user B is authenticated as user A.</div><div><br></div><div>Andreas</div></div>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>