<div dir="ltr">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.<div><br></div><div>I have a proposal for how to address this limitation:</div><div><br></div><div>The front-channel logout and back-channel logout drafts both define the "sid" claim. There is some discussion of it here, too: <a href="https://bitbucket.org/openid/connect/issues/1031/sid-id-token-claim-definition-and-when-to">https://bitbucket.org/openid/connect/issues/1031/sid-id-token-claim-definition-and-when-to</a> .</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>What do you think? Is this a viable approach?</div><div><br></div><div>Thanks,</div><div>Jake Feasel</div><div>ForgeRock, Inc.</div><div><br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"></div></div></div>

<br>
<span style="color:rgb(23,43,77);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;background-color:rgb(255,255,255)"><font size="1">ForgeRock values your <a href="https://www.forgerock.com/your-privacy" target="_blank">Privacy</a></font></span>