This is a more in-depth follow-up of the issue I raised in ticket #8359 The OpenID Connect Front Channel Logout specification defines the notion of a [Session ID](https://openid.net/specs/openid-connect-frontchannel-1_0.html#Terminology): >String identifier for a Session. This represents a Session of a User Agent or device for a logged-in End-User at an RP. Different sid values are used to identify distinct sessions at an OP. The sid value need only be unique in the context of a particular issuer. Its contents are opaque to the RP. Its syntax is the same as an OAuth 2.0 Client Identifier. This Session ID is passed back and forth between the OP and RP in a number of protocol exchanges, either using a `session_id` query parameter, or else as a `sid` claim within an ID Token or a Logout Token. Like any normal web application, oxAuth maintains a session with the user-agent using a [session token](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-properties) stored in a browser cookie. Perhaps due to an unfortunate choice of names, the cookie oxAuth uses to store its session token is also called `session_id`. This may have led to a misconception that the session token used to maintain a stateful browser session is the same thing as the Session ID used by RPs to perform backchannel/frontchannel logout. This seems to be the case with oxAuth today, but it must not be, for important security reasons. *I have to place some fault on the OpenID Foundation for choosing the term "Session ID". The SAML specifications use a much better name: "Session Index".* When oxAuth, as an OP, discloses the value of its session token to an untrusted RP (either in a `session_id` query parameter or `sid` claim), that RP is now able to [hijack](https://owasp.org/www-community/attacks/Session_hijacking_attack) the user's browser session at the OP, which in turn could allow them to establish new sessions at other RPs (via Single Sign-On). This is a *Very Bad Thing*. We are in the very early stages of our roll-out, and have been able to mitigate this vulnerability by blocking the disclosure using the web server (effectively disabling this feature of the front-channel logout spec). Our medium term requirement is to fully support both front-channel and back-channel logout, so we would really appreciate seeing a different value used for the logout Session ID than the one used for maintaining the browser session. Cheers, -Doug