<div dir="ltr"><br><br><div class="gmail_quote">On Tue Feb 24 2015 at 13:18:41 John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I don’t actualy think we need a signed token in the front channel.<div><br></div><div>I am talking about using a signed token in the back channel, but that is quite different, as all of the session information needs to be derived from the token as the RP has no session cooke.</div><div><br></div><div>In the front channel there are two issues.</div><div><br></div><div>1 what account to sign out if there is more than one logged in from the IdP</div><div>2 is this from the IdP or a cross site request forgery.</div><div><br></div><div>1 could be solved by including the subject or a session identifier.</div><div>2 The sid alone should be sufficient to stop a XSRF unless the id_token has leaked.</div></div></blockquote><div><br></div><div>Correct me if I'm wrong, but t<span style="font-size:13.1999998092651px">he id_token will leak for an RP using the Authorization Code Flow and operating over an unencrypted channel, when redirecting to the authorization endpoint with the id_token_hint to renew an access_token: the RP sends a 303 to the browser over HTTP (instructing him to go fetch the authorization endpoint with an id_token_hint).</span></div><div><span style="font-size:13.1999998092651px">It could also possible happen with the Hybrid Flow I suppose (Implicit Flow requires the RP to use HTTPS; well, at least for the redirect_uri…)</span></div></div></div>