[Openid-specs-ab] Frontchannel logout: logging out when no iss is provided

Vladimir Dzhuvinov vladimir at connect2id.com
Mon Nov 2 18:04:40 UTC 2020

Hi Tangui,

On 31/10/2020 12:15, Tangui Le Pense via Openid-specs-ab wrote:
> I’m a bit late to the party, so sorry if these points have already
> been discussed.
> I’m currently implementing frontchannel logout
> (https://openid.net/specs/openid-connect-frontchannel-1_0-04.html) in
> an RP and in case `iss` (and `sid`) is not provided when the OP hits
> the frontchannel logout URI, I was wondering:
> - can’t any site open this URI in a iframe and trigger logout? A site
> periodically refreshing such a malicious iframe would result in kind
> of a DOS attack. If the RP is not capable of temporarily saving form
> data, it could be even more annoying for the user experiencing data
> loss. Sure, if it that happens, the RP will redirect to the OP which
> will probably seamlessly redirect back to the RP with an new ID token.
> But this is not documented as a security risk or anywhere else, which
> is why I’m wondering if I’ve just missed something here

My suggestion is to only act on iss & sid being present, because
otherwise you can't really tell where the request is coming from. And
there is no CSRF or user confirmation that can be invoked.

Front-channel logout is per definition unreliable. OPs that silently
expire a user's session, for example, will have no way to notify the RP.
The front-channel notification can only work when the end-user is at the
OP and chooses to log out there, or the OP is open in some browser tab
and the expiration happens.

> - if the RP can have several sessions opened from different OPs, how
> can the RP know which OP to logout from? For now I’m sticking to a
> «kill all sessions» approach, but it’s not satisfying

You can trying registering a per OP frontchannel_logout_uri. But again,
insist on registering the RP for receiving the iss & sid.


Vladimir Dzhuvinov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20201102/955614ae/attachment.p7s>

More information about the Openid-specs-ab mailing list