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

George Fletcher gffletch at aol.com
Thu Jun 6 01:26:48 UTC 2019


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 
> <mailto: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
>     <mailto: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/20190605/83918b56/attachment.html>


More information about the Openid-specs-ab mailing list