[Openid-specs-ab] Third-Party Cookies and Front Channel Logout

Filip panva.ip at gmail.com
Wed Dec 7 12:47:14 UTC 2016


I can confirm that Session Management 1.0 suffers the same fate, OPs
relying on a cookie presence aren't able to calculate the same session
state, always resulting in "changed" state.

With 3rd party cookies disabled
OP frames loaded from RP origin - OP cookies are not available
RP frames loaded from OP origin - RP cookies are not avaialble (d'oh).

In addition, the RP must not block it's front_channel_logout_uri from being
iframed. That means either not using X-Frame-Options header at all for the
page, or using `X-Frame-Options: ALLOW-FROM https://op.example.com/` to
whitelist OP origins that are able to execute the frontchannel logout. OP
and RP should agree on what the OP logout origin will be in this case.
Whitelisting the origins is recommended if `iss` & `sid` is not being used
by the RP to prevent unintended or potentially exploitable logouts.

There are additional restrictions for P3P enabled User-Agents where non P3P
declaring pages won't have their cookies sent to the server when iframed.
These Agents are, as far as i am aware all IE versions on non-Windows 10
systems.

But since P3P is no longer supported (
https://msdn.microsoft.com/en-us/library/mt146424(v=vs.85).aspx) i think
there's no harm in abusing the spec's definition and completely bypass it
by sending an invalid P3P header value from the server when it detects a
relevant IE version in the user agent. (This obviously applies to Session
Management 1.0 as well, since the OP frame won't be able to access the
cookies it needs to calculate the matching session state, reporting either
error or session changed).

I can think of ways to have session management implementation rely on
localStorage, making that one work, however, can't figure out a workaround
for changing RP states via an iframe or any other frontend element means.

Best,
*Filip Skokan*

On Mon, Aug 29, 2016 at 10:09 PM, Prateek Mishra via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Agreed, Torsten, we would like to see a solution to the problem as well.
>
> I believe that the “OpenID Session Management 1.0” specification suffers
> from the same problem,
> but I have personally not worked with this specification.
>
> Mike - could we please add this issue to the next AB call agenda?
>
> Thanks,
> prateek
>
> On Aug 29, 2016, at 8:48 AM, torsten at lodderstedt.net wrote:
>
> Hi Pratek,
>
> we are facing the same problem. Describing it in the spec is definitely
> the minimum. Better would be to come up with a viable solution.
>
> best regards,
> Torsten.
>
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your
> emails as clean, short chats.
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Prateek Mishra via Openid-specs-ab <openid-specs-ab at lists.openid.net>
> Gesendet: Friday, August 26, 2016 02:56 AM
> An: openid-specs-ab at lists.openid.net
> Betreff: [Openid-specs-ab] Third-Party Cookies and Front Channel Logout
>
> The OIDC Front Channel Logout draft specification uses HTTP GETs to RP
> URLs that clear login state.
>
> http://openid.net/specs/openid-connect-frontchannel-1_0.html
>
> This typically takes the form of an OP loading a page with <iframe
> src="frontchannel_logout_uri”> or <img src=“front_channel_logout_uri”>
>
> However, modern browsers allow users to “block third party cookies” and
> this setting means that the logout at the RP will fail (unable to remove
> previously
> established RP cookie). Our implementation and test teams have found this
> to be a really confusing situation for end-users.
>
> Have implementors had any success with alternatives or work-arounds? At a
> minimum we should capture this behavior in the draft specification.
>
> Thanks,
> prateek
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20161207/4597d418/attachment.html>


More information about the Openid-specs-ab mailing list