[Openid-specs-ab] Safari Patch and clearing local storage

Reman Child remanc at gmail.com
Fri Jun 7 16:21:06 UTC 2019


Yeah, that definitely seems to meet the criteria, especially with the no
user interaction redirect.

I haven't been following as closely recently, but have there been
discussions on allowing refresh tokens for SPAs if they're
sender-constrained? I.e. if you're using code/PKCE + DPoP and the DPoP
private key is marked non-extractable, it seems to address some security
concerns around refresh tokens in the browser. The idea here being to
side-step this new webkit behavior by reducing (or maybe eliminating?) the
need to redirect to the OP for any flow where we don't have explicit user
interactions in the SPA first.

If the SPA does get into a case where it needs to redirect to the OP, and
it has storage that must-not-be-cleared (i.e. the DCR clientId), it does
feel like its no longer safe to do this without user interaction - the SPA
would have to present a button to redirect rather than doing it
automatically. Similar to how the earlier ITP2 changes affected the SPA
hidden iframe token renewal flows - there was no longer a way to unlock
third-party session cookies without a user interaction to use the new
storage access apis.

/r

On Wed, Jun 5, 2019 at 6:26 PM George Fletcher <gffletch at aol.com> wrote:

> Thanks so much for your response.
>
> So here is how I was thinking of using Dynamic Client Registration (DCR)
> for a browser based app. Think something more akin to a Single Page App.
> The App loads in the browser. The browser uses the Crypto JS library to
> create a pub/priv key pair. The App uses Dynamic Client Registration to
> register the public key. Now the browser has a unique client_id to use for
> any future calls. In this context, the App would need to store the private
> key in localStorage/indexDB. If localStorage is cleared then the private
> key is gone and the DCR is pointless. Note that in this context the private
> key could also be used for sender-constrained tokens with DPOP as an
> example.
>
> In regards to user-interaction... in some cases where user authentication
> is required, the user is redirected without any user interaction because
> they are not logged in. In this context the local storage would be cleared
> and the calls to the token endpoint would fail (as you outlined below).
> Think entering mail.google.com as the URL in the browser:)
>
> Thanks,
> George
>
> On 6/4/19 11:06 AM, Reman Child wrote:
>
> Hi George,
>
> Can you explain more about why you think this breaks Dynamic Client
> Registration in the browser?
>
> Looking at the code [1], it seems like this should only affect the RP in
> these flows and not the OP. If I'm reading it right, this is the expected
> behavior:
> - RP initiates some flow against the OP through a redirect
> - OP is prevalent (category where this and other ITP2 behavior kicks in)
> - OP redirects back to RP with link decoration
> - RP localStorage/indexedDB is cleared
>
> So, an affected flow could be something like the new proposal to use PKCE
> & auth code for browser apps [2] if it uses localStorage/etc for the
> code_verifier:
> - RP stores code_verifier in localStorage, initiates authorization request
> - OP is prevalent, redirects back to RP with link decoration (i.e. code,
> etc)
> - Safari clears localStorage i.e. code_verifier, RP can't make token
> request
>
> But, as part of the check for removing storage [3], the code also looks
> for user interaction - in this example, if the user has interacted with the
> RP in the last 7 days (i.e. when the user clicked sign-in to initiate the
> request), it won't clear it. So at a first glance it feels like the effect
> for RPs is minimal.
>
> [1]:
> https://github.com/WebKit/webkit/commit/39bc7b05175f71915597e7001594e703247668eb
> [2]: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-01
> [3]:
> https://github.com/WebKit/webkit/commit/39bc7b05175f71915597e7001594e703247668eb#diff-0de9e6ac983b05b8b15a3f1054bc74e5R812
>
> /r
>
> On Wed, May 29, 2019 at 12:45 PM George Fletcher via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> Hi,
>>
>> Just curious if this new merge to clear local storage, could affect
>> OpenID Connect providers who might store some information in local
>> storage during the authentication event. I think this pretty much breaks
>> Dynamic Client Registration from a browser. Given all flows have
>> parameters (considered link decoration) it seems like standard flows
>> might also be affected.
>>
>> https://bugs.webkit.org/show_bug.cgi?id=195923
>>
>> Other experiences?
>>
>> Thanks,
>> George
>>
>> _______________________________________________
>> 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/20190607/284567ab/attachment.html>


More information about the Openid-specs-ab mailing list