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

[David Waite]

Hello Jake!

I attempted to define something similar to this a while back,
https://bitbucket.org/openid/connect/raw/293dca14cd1352bbb101d15bcac4a6f3825a4b15/distributed-token-validity-api.txt <https://bitbucket.org/openid/connect/raw/293dca14cd1352bbb101d15bcac4a6f3825a4b15/distributed-token-validity-api.txt>

The motivation was to:
1. Create an API which could easily be proxied/cached such that an RP could run their own infrastructure for checking validity (for scaling/reliability/latency reasons)
2. Investigate ways other than reactive HTTP proxying to synchronize this data, such as using a distributed ledger (described in a separate proposal in the same repo).

In retrospect, #2 was a step too far - I also was planning an investigation of using secevent-based signalling, but dropped this due to low interest.

I did a presentation on this on the last IIW; I got the impression that the slow death of third party cookies had increased interest in this sort of approach, but I personally don’t have time to lead that effort at the moment.

-DW

> On Jun 18, 2021, at 9:13 PM, Jake Feasel via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> 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 <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?
> 
> -- 
>  <https://www.forgerock.com/>	Jake Feasel
> Principal Engineer |  ForgeRock
> t (907) 229-1865  |  e jake.feasel at forgerock.com <mailto:firstname.lastname at forgerock.com>
> twitter jakefeasel  |  web www.forgerock.com <https://www.forgerock.com/>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>_______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210618/79750405/attachment.html>