Front-channel logout that doesn't rely on cookies

[Jens Borgland]

The front-channel logout mechanism has a major advantage compared to the back-channel logout mechanism in that it works even behind a firewall or such. It however relies on cookies (to determine which session should be logged out) which gives two problems:

1. It lacks CSRF protection, opening up for Denial of Service attacks (an attacker that can trick a user to load a certain page can silently log the user out of another site)
2. It may not work - due to users disabling third-party cookies or RPs using SameSite cookies (see issue #1003)

With Chrome moving to SameSite=Lax by default this becomes a major problem. The problem with SameSite cookies can of course be “solved” by RPs setting SameSite=None - but that opens up for the kind of CSRF attacks that it’s intended to protect against.

To solve this I propose a new version of front-channel logout that takes a logout token (just like the one used in back-channel logout). Having such a token completely removes the reliance on cookies - solving both of the above mentioned problems. It may be a bit harder to implement (for both OPs and RPs) but not harder than back-channel logout.

Perhaps the specification should require that logout tokens are encrypted (for back-channel logout that seems completely unneccessary).

[Tom Jones]

The whole concept of openID Connect was oriented to cookies and support for Google/MSFT/FB. Those do not allow logout from relying parties, so there seems to be little reason to make this change to OIDC.

There is a process of whack-a-mole going on with the introduction or PAR, RAR and open banking to get around the limitations of bearer tokens, which still serve the intended purpose with the big IdPs.

What is new is that OIDC is making in-roads to private networks, which is not openID and doesn’t really belong in OIDC at all.

So, my humble suggestion is to stop all these incremental changes and start a new core spec for closed systems. I guess we could still pretend it is open. Something like OpenID Universal or some such?

Also i have built a system for self-issued IDs which also depends on signed and encrypted packets, so that could be included and delete section 7 of the oidc core spec as that really doesn’t work with current smart phones.

[Jens Borgland]

@Tom Jones
OIDC is very widely used outside those three public providers that you mention (FB doesn’t even implement OIDC by the way) - including in other services and products from MSFT (like Azure AD and ADFS) that do support logout. I agree that the original intent of users being able to use their OpenID from more or less anywhere more or less everywhere (using dynamic registration, discovery etc) hasn’t actually worked (there are very few providers that implement those things) but OIDC still provides a lot of benefit in a wide range of scenarios - and I see no reason to create a separate standard for more or less religious reasons.

Your proposal regarding self-issued providers should probably be treated in a separate issue don’t you think?

[Tom Jones]

I guess my message was not clear. OIOC is based on OAuth and bearer tokens. Now we understand attacks against them, it is time to abandon front channel limitations and reliance on channel security. I propose a new standard without the need for channel security (it may still be used, but not depended on) in favor of a fully signed and encrypted exchanges of application level messages. Is that clear?

[Brian Campbell]

Some folks are trying to propose a new standard over at https://datatracker.ietf.org/wg/txauth/about/ FWIW

[Tom Jones]

Thanks, that’s interesting. I sent a note to dick to see if my team’s spec is covered. I haven’t found their drafts yet, which they seem to have even though they are not yet chartered. That’s interesting too. BTW, our spec is for high assurance for health care, which is not handled by open id.

[David Waite]

The front-channel logout mechanism has a major advantage compared to the back-channel logout mechanism in that it works even behind a firewall or such. It however relies on cookies (to determine which session should be logged out) which gives two problems:

While front-channel logout (and implicit flow) do work without systems needing direct network connectivity, I do not believe that was meant to be the primary benefit or even listed as a secondary benefit.

Rather, implementors of logout who prefer front-channel do so because the cookies are present in the front channel - it allows you to implement logout by having a simple endpoint which deletes session cookies. With back channel, you must have either stateful sessions or a stateful session revocation list made available to all relevant endpoints.

Merely changing the spec to send a token will hide the complexity of that implementation change from RPs. If I don’t have visibility to a session cookie due to ITP or SameSite (or any of the other reasons a site may open in a different state context), I must use a stateful mechanism to implement logout. That is AFAIK a completely different implementation than most front-channel logout implementations today.

‌

[Michael Jones]

I think DW’s comment accurately captures the intent and the situation.

[Michael Jones]

This proposes a completely different front-channel logout mechanism

[Michael Jones]

This requests a new spec, which we're not planning to do at this time. Placing on hold for now, per the discussion on the 9-Apr-20 call.

[Andrew Korshunov]

For anybody finding this topic and wondering if there is a way to still have the advantage of having your authentication ticket cookie being SameSite=LAX and at the same time using front-channel logout, I have came up with some sort of a workaround.

Basically, you need to modify your system in such a way that it needs two cookies/tickets in every request to authenticate a user, one cookie is your main authentication ticket which would be SameSite=LAX and the other one is a less secure (SameSite=NONE) but still required. This second cookie will be used to track front-channel logout and since it’s SameSite=None, SSO provider can delete it from within the hidden iFrame. This cookie is necessary for using the system but alone it won't do anything so it is safe to have it SameSite=None.

In other words, you need two keys to open the door and one key is easier to steal than the other, but you need both to open the door so the overall security is still good. If an attacker steals one key, they won’t be able to open the door. But one of the keys being less secure allows for it to be taken away from the user by a third-party. Thus if the second key has been stolen from you, even though you still have the first secure key, you wont be able to use that one alone to open the door - you need both.

One of the ways to do this is to have a new claim in your main ticket (SameSite=LAX) called something like LogoutToken and also store it as part of a LogoutTicket cookie (SameSite=None). The token should be crypto-random generated phrase. Every request you need to validate that not only the main auth ticket is present, but also that the logout ticket is present and it's value matches the one stored in main auth ticket claim. If only main auth ticket is present, we deny access to the site and remove the existing main ticket.

On the front-channel logout endpoint the LogoutTicket cookie should get removed, the user will be left with only the main ticket.

[Michael Jones]

Again, per the discussion on the 9-Apr-20 working group call (more than two years ago), this is an entirely different (and fourth) logout mechanism. If you want to write a new specification defining this mechanism, that would be the next step forward towards making this concrete.

[Andrew Korshunov]

My comment is not about updating the OIDC spec, it’s about how to make it work with the current spec for those having the same problem and finding this issue.