<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>I have a proposal for how to address this limitation:<br><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>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.</div><div><br>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.</div><div><br>What do you think? Is this a viable approach?<br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><table border="0" cellspacing="0" cellpadding="0" style="font-family:"Times New Roman""><tbody><tr><td valign="center"><a href="https://www.forgerock.com/" target="_blank"><img src="https://www.forgerock.com/img/2019_forgerock_email_logo_retina.png" width="185" height="70" border="0" alt="ForgeRock"></a></td><td valign="top" align="left" bgcolor="#ffffff" style="font-family:arial,helvetica,verdana,sans-serif;font-size:12px;color:rgb(47,52,56);line-height:19.8px"><span style="color:rgb(3,43,117)"><strong>Jake Feasel</strong></span><br>Principal Engineer |  ForgeRock<br><span style="color:rgb(249,103,0)"><strong>t</strong></span> (907) 229-1865  |  <span style="display:inline-block"><span style="color:rgb(249,103,0)"><strong>e</strong></span> <a href="mailto:firstname.lastname@forgerock.com" style="color:rgb(47,52,56)" target="_blank">jake.feasel@forgerock.com</a></span><br><span style="color:rgb(249,103,0)"><strong>twitter</strong></span> jakefeasel  |  <span style="display:inline-block"><span style="color:rgb(249,103,0)"><strong>web</strong></span> <a href="https://www.forgerock.com/" style="color:rgb(47,52,56)" target="_blank">www.forgerock.com</a></span></td></tr></tbody></table></div></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>