[Openid-specs-ab] Issue #1149: Front-channel logout that doesn't rely on cookies (openid/connect)

Jens Borgland issues-reply at bitbucket.org
Fri Jan 31 19:42:10 UTC 2020


New issue 1149: Front-channel logout that doesn't rely on cookies
https://bitbucket.org/openid/connect/issues/1149/front-channel-logout-that-doesnt-rely-on

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](https://bitbucket.org/openid/connect/issues/1003/document-possible-impacts-of-disabling)\)

With Chrome moving to [SameSite=Lax by default](https://www.chromium.org/updates/same-site) 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\).




More information about the Openid-specs-ab mailing list