[Openid-specs-ab] OIDC Session Management and third party cookie blocking

Fri Sep 2 15:19:08 UTC 2022

what's the threat from the spa (aka pwa) running on w/o knowing that the
session is no longer active?
Who is it that cares until the app tries to access a remote resource?
Please don't tell me that the app should not be allowed to access a local
resource on the computer!  Who's computer is it exactly?

Be the change you want to see in the world ..tom

On Thu, Sep 1, 2022 at 6:48 PM Vittorio Bertocci via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> I am not sure there's the need to introduce new endpoints and grants for
> this.
> The scenario initially identified is the pure SPA, where the app cannot
> rely on a backend component. The main primitive is an affordance for the
> app to verify whether there's still an active OP session, eg no other RP
> participating in the OP session triggered a sign out.
> You can easily obtain that affordance by implementing session bound
> refresh tokens. If your refresh tokens are session bound, attempts to use
> them when the session is no more will fail. Simple. Existing endpoints,
> artifacts, grants.
> If your refresh tokens are meant to be used with a SPA, their lifetime
> should have an upper bound tied to the session anyway - SPA SDKs
> implementing the code grant routinely drop from whatever local cache they
> maintain access and refresh tokens upon their own sign out, hence having
> refresh tokens surviving that is a security hindrance anyway. In fact, some
> vendors even require calling their token revocation APIs on logout (which
> wouldn't be necessary if their refresh and access tokens would
> automatically be invalidated when the session it originated them
> terminates).
> One of the challenges of the above (already discussed on this list a while
> ago) is that although it is a perfectly legitimate behavior for  the
> authorization server, we have no interoperable way to request it. In fact,
> the only affordance ever offered to request a refresh token is the famous
> "offline_access" scope, that does the exact opposite (refresh tokens are
> now guaranteed to be decoupled from the session) and many providers use
> that scope as the ONLY way to cause their authorization server to issue
> refresh tokens, which complicates things. Even ignoring that, basically the
> behavior of refresh tokens is at complete discretion of the authorization
> server hence today there's no way to know whether the refresh token as
> check session trick will work.
> At Okta we implemented "online_access", a scope that causes our
> authorization server to issue refresh tokens that will automatically become
> invalid when the corresponding OP session is terminated (eg because of a
> logout). Few years ago we suggested standardizing it, but there was
> pushback on the account that "offline_access was a mistake hence adding
> online_access would be doubling down", if I remember correctly. If the
> browser crisis is making people reconsider, there should still be the draft
> somewhere :-)
>
> On the inactivity timeout. One thing that gets lost with using RTs rather
> than iframe tricks for session renewal is that RTs no longer "touch" the
> authorization endpoint, hence cannot extend the life of session cookies
> with sliding expiration settings. This isn't a trivial problem: whether one
> uses the token endpoint as I described here or a new backend (eg nonbrowser
> UX) endpoint, allowing a backend operation to affect a front channel
> session would mix two completely different threat models, and throw away
> all the protective measures we already have in place on the authorization
> endpoint (eg anomaly detection based on signal entropy of the front
> channel). I don't think we can safely get back session extension
> functionality without first getting some mechanism to prove that calls to
> the token endpoint are coming from the same user agent that benefited from
> the initial session setting top level redirects. Sender constraint of some
> form, perhaps.
>
>
> On Tue, Aug 30, 2022 at 6:13 PM Jake Feasel via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> *This message originated outside your organization.*
>>
>> ------------------------------
>>
>> While this concern is important, if we follow it through completely it
>> kills the entire auth code grant for the same reasons. Looking at it from
>> the browser point-of-view, the auth code grant is just some redirection
>> across domains involving the transmission of an opaque "code" generated by
>> the OP back to the RP, followed by an additional call from the RP to the OP
>> passing it back; who is to say that this code isn't used for tracking users
>> across sites?
>>
>> "The browser people don’t seem to care about that at the moment." - There
>> is a good reason why the privacy-conscious should not be opposed to this
>> general technique (both the auth code and the proposed session check
>> grants). Both grants can only work in a third-party cookie blocking
>> environment if the browser is redirected through the OP at the top-level
>> (i.e. as a first party interaction). I believe this is the critical point
>> that shifts the usage from "nefarious" to "legitimate".
>>
>> Put another way - if a privacy-abusing marketing company wanted to try to
>> copy this pattern for their own nefarious purposes, they would have to
>> require every page they advertise on to have a top-level redirect for all
>> visitors through their own domain and back again (passing the requisite
>> tracking id back in the URL). I feel like this extremely obtrusive pattern
>> would not be acceptable for most pages that just want to show ads - it's
>> only acceptable in the case of authentication because the site and the user
>> have very tangible benefits from the interruption in flow associated with
>> logging in.
>>
>> I think we are on safe ground here, in terms of what patterns are likely
>> to be shut down in the future. As such I would like to continue with this
>> "session_check" grant proposal.
>>
>> Thanks
>>
>>
>>
>> On Wed, Aug 10, 2022 at 3:25 AM Mischa Salle via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> On Tue, Aug 09, 2022 at 06:39:27PM +0000, Nicole Roy via Openid-specs-ab
>>> wrote:
>>> > My concern would be that a browser employing “Intelligent Tracking
>>> Prevention” would see the POST of the SID as tracking and prevent it. Of
>>> course, doing so breaks all sorts of other things, but the browser people
>>> don’t seem to care about that at the moment.
>>>
>>> probably would have the same problems with "nonce" and "state" then?
>>> Plus makes one wonder whether these three could not have been a single
>>> parameter?
>>>
>>> Mischa
>>>
>>> > > On Aug 2, 2022, at 4:30 PM, Jake Feasel via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>> > >
>>> > > This topic has been raised before, but based on the traffic from
>>> this list it seems to not be going anywhere. I would like to revive it.
>>> > >
>>> > > I had a quick talk at Identiverse this year covering the OIDC
>>> Session Management draft spec, in particular my take on the upcoming
>>> "Cookiepocalypse" and how it will render the current draft completely
>>> obsolete. You can see my slides here:
>>> https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63
>>> <
>>> https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63
>>> >
>>> > >
>>> >
>>> > [snip]
>>> >
>>> > > The OP will include the "sid" claim (as defined in the Front and
>>> Back-channel logout drafts) as a claim in the id_token used in an auth_code
>>> grant. This "sid" value will be included in a POST request to the "token"
>>> endpoint on the OP on a periodic basis (likely prompted from user activity
>>> within the RP). It would like something like so (note the absence of a
>>> cookie in this request):
>>> > >
>>> > >   POST /token HTTP/1.1
>>> > >   Host: server.example.com
>>> <https://urldefense.com/v3/__http://server.example.com__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULQ7mR5vWQ$>
>>> <http://server.example.com/
>>> <https://urldefense.com/v3/__http://server.example.com/__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULSFUiVTrA$>
>>> >
>>> > >   Content-Type: application/x-www-form-urlencoded
>>> > >   Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>>> > >
>>> > >   grant_type=session_check&sid=1234xyz
>>> > >
>>> > > The response code from this could be a 401 if the sid is not
>>> associated with a valid OP session, or 200 if it is. The response body in
>>> the case of a 200 could include a new id_token with updated session claims
>>> (to provide better context for when the session expires or if other
>>> important details about the session change).
>>> > >
>>> >
>>> > [snip]
>>> >
>>>
>>>
>>>
>>> > _______________________________________________
>>> > Openid-specs-ab mailing list
>>> > Openid-specs-ab at lists.openid.net
>>> > https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULRsA0bY8A$>
>>>
>>>
>>> --
>>> Nikhef                      Room  1.14
>>> Science Park 110            Tel.  +31-6-4681 2202
>>> 1098 XG Amsterdam           Fax   +31-20-592 5155
>>> The Netherlands             Email msalle at nikhef.nl
>>>   __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULRsA0bY8A$>
>>>
>>
>>
>> --
>> [image: ForgeRock]
>> <https://urldefense.com/v3/__https://www.forgerock.com/__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULQN6gZ7BA$> *Jake
>> Feasel*
>> Sr. Product Manager, IDM |  ForgeRock
>> *e* jake.feasel at forgerock.com <firstname.lastname at forgerock.com>
>> *twitter* jakefeasel  |  *web* www.forgerock.com
>> <https://urldefense.com/v3/__https://www.forgerock.com/__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULQN6gZ7BA$>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://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/20220902/572329cc/attachment.html>