Hi Martin, I’ve picked in on a few of your comments.
> The text is now: > >> A practical implementation pattern can use a Web Worker [WebWorker] to >> isolate the refresh token, and provide the application with the access token >> making requests to resource servers. This prevents an attacker from using >> the application's refresh token to obtain new tokens. > > This all seems to hinge on a web worker being "highly isolated" (see previous > paragraph), which I think is overstating it a little. It might be easier to > isolate a worker, but you have to acknowledge that compromised main thread JS > can install or replace workers. At best, I would say "more isolated" or > "more easily isolated". Seems fair, I have updated the text to “more isolated”. >> We've updated all mentions of "perfect storage" to phrases like >> "...even a token storage mechanism that completely isolates the tokens >> from the attacker..." Hopefully this is clearer. > > Indeed it is. Though I still think that "perfectly" and "completely" are a > little more absolute than you can justify. None of this stuff is perfect. Just to clarify, the use of perfectly/completely in this context is purely hypothetical to indicate that even if such a mechanism were to exist, it would still not counter the other attack scenarios. The main reason this part is in there, is because a common reaction to hearing about the security limitations is for people to come up with ways to protect the tokens. This often leads to convoluted solutions that do not offer the protections people think they do (and as you point out). And even if they do exist, the attacker can simply request new tokens and completely ignore the tokens stored in the perfect storage solution. > >>> In Section 8.5, please consider de-emphasis of local storage. Browsers have >>> been trying to move people off the jank-inducing API for more than a decade >>> now. Anything that uses storage needs to be asynchronous, local storage >>> isn't. >> >> I added a mention of localStorage being synchronous. > > That's not quite what I was angling for. Your central point is independent > of technology/API. It is that if you stick a token in [a store] and you have > compromised code running in the same origin anywhere, that code can access > the store and get your token. So, rather than talking about specific types > of stores (other than listing examples) I would trim the section down to the > simpler statement. (sessionStore being somewhat ephemeral is not a useful > distinction here, mostly because the idea of "session" is so vague as to be > useless: many browsers restore sessions after a restart) In the context of this document, I believe the distinction between different types are needed, precisely for the point explained above. People will naturally go looking for “secure token storage” options, so listing them here ensures they will find an answer to their questions. I did further clarify that IndexedDB is asynchronous and preferred over localStorage. Thank you for taking the time to carefully review this document. Kind regards Philippe — Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
