[Openid-specs-ab] Spec call notes 23-Feb-15
t.broyer at gmail.com
Thu Feb 26 09:45:59 UTC 2015
On Tue Feb 24 2015 at 13:18:41 John Bradley <ve7jtb at ve7jtb.com> wrote:
> I don’t actualy think we need a signed token in the front channel.
> 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.
> In the front channel there are two issues.
> 1 what account to sign out if there is more than one logged in from the IdP
> 2 is this from the IdP or a cross site request forgery.
> 1 could be solved by including the subject or a session identifier.
> 2 The sid alone should be sufficient to stop a XSRF unless the id_token
> has leaked.
Correct me if I'm wrong, but the 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).
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…)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab