[Openid-specs-ab] OIDC Session Management and third party cookie blocking

[Jake Feasel]

This topic has been raised before, but based on the traffic from this list
it seems to not be going anywhere. I would like to revive it.

I had a quick talk at Identiverse this year covering the OIDC Session
Management draft spec, in particular my take on the upcoming
"Cookiepocalypse" and how it will render the current draft completely
obsolete. You can see my slides here:
https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63

The main points:

- The current session management spec already identifies its own demise,
here:
https://openid.net/specs/openid-connect-session-1_0.html#ThirdPartyContent

- IDP-initiated logout and idle timeout reset will be unavailable once
third party cookies are blocked (if there is no alternative solution
available)

- Back-channel logout is a viable (albeit challenging to implement)
alternative for apps which have a back-end; pure client-side single page
apps do not have this option, however.

The biggest point I want to raise is that we need an alternative
implementation to become the new standard; one that is not susceptible to
third-party cookie blocking. To that end, I propose the introduction of a
new grant type - "session_check". It would work like so:

The OP will include the "sid" claim (as defined in the Front and
Back-channel logout drafts) as a claim in the id_token used in an auth_code
grant. This "sid" value will be included in a POST request to the "token"
endpoint on the OP on a periodic basis (likely prompted from user activity
within the RP). It would like something like so (note the absence of a
cookie in this request):

  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

  grant_type=session_check&sid=1234xyz

The response code from this could be a 401 if the sid is not associated
with a valid OP session, or 200 if it is. The response body in the case of
a 200 could include a new id_token with updated session claims (to provide
better context for when the session expires or if other important details
about the session change).

Any client which is capable of calling the token endpoint in an auth_code
grant should be just as capable of making a similar request to the token
endpoint for this new session_check grant. All of the same authentication
methods used for an auth_code grant should be suitable for this grant too
(meaning public clients such as SPAs and Mobile apps should also be able to
call it).

Another advantage of this approach is that it could be performed completely
in the back-channel. Confidential clients which have never had access to
the OP session cookie could make a session_check request and learn whether
or not the user is still logged in.

I am eager to hear others' thoughts on this. I haven't contributed to a
spec before, so any guidance you can offer to that end would be welcome.

Thanks,
Jake Feasel

-- 
[image: ForgeRock] <https://www.forgerock.com/> *Jake Feasel*
Sr. Product Manager, IDM |  ForgeRock
*e* jake.feasel at forgerock.com <firstname.lastname at forgerock.com>
*twitter* jakefeasel  |  *web* www.forgerock.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220802/9f6c86ed/attachment.html>