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

Jake Feasel jake.feasel at forgerock.com
Tue May 11 01:03:13 UTC 2021


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 and last the "nonce" value. In exchange, 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 (a new nonce and maybe 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. 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?

Thanks,
Jake Feasel
ForgeRock, Inc.

-- 
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/20210510/09707ef3/attachment.html>


More information about the Openid-specs-ab mailing list