[Openid-specs-ab] OIDC Session Management challenges with ITP

[Jake Feasel]

Based on my searching of the mailing-list archives, it appears to me that
there is a wide-spread acknowledgement of the problem that third-party
cookie restrictions impose on the current OIDC Session Management draft
spec. In short - using hidden iframes with prompt=none to check the session
status at the OP is not viable when browsers are restricting the OP session
cookie.

I have a proposal for how to address this limitation:

The front-channel logout and back-channel logout drafts both define the
"sid" claim. There is some discussion of it here, too:
https://bitbucket.org/openid/connect/issues/1031/sid-id-token-claim-definition-and-when-to

My understanding from reading these specs is that both have the assumption
that the "sid" claim is first given to the RP in the id_token as part of
initial authentication. I would like to build upon that assumption and
suggest that this claim could be used as the basis for a new grant -
"session_check" or some such. It could be another call to the token
endpoint, secured in much the same way as the original auth code grant
(verifying client_id, redirect_uri, etc...). Rather than the code, it would
pass the "sid" value. In response, if the session identified by the sid is
still current in the OP the RP would get back a new id_token with updated
claims (exp, acr, auth_time, etc...). It would be reasonable to assume that
if the session in the OP has an idle timeout, this call from the RP would
reset that timeout.

I don't see any obvious reason why such a grant would not work well for any
RP that is currently capable of performing an authorization code grant -
including single page apps without a back-end component (relying on CORS).
This has the advantage of avoiding all iframe and cookie limitations, while
building upon existing patterns such as the "sid" claim.

What do you think? Is this a viable approach?

-- 
[image: ForgeRock] <https://www.forgerock.com/> *Jake Feasel*
Principal Engineer |  ForgeRock
*t* (907) 229-1865  |  *e* jake.feasel at forgerock.com
<firstname.lastname at forgerock.com>
*twitter* jakefeasel  |  *web* www.forgerock.com

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210618/eb72a879/attachment.html>