5 ms·
That's an interesting question, but what exactly is the threat model here? A rogue extension somehow reading the token? Is it stored anywhere? AFAIK generally t
by apitman 2y ago
That's an interesting question, but what exactly is the threat model here? A rogue extension somehow reading the token? Is it stored anywhere? AFAIK generally the concern with access tokens is that they get gleaned from logs or MITM, not pulled out of the browser's memory.
- taeric 2y agoSure, but there are also good habits? I get not having the token in the url is a logs protection. I'm less clear on storing it in local storage.
- apitman 2y agoI'm not sure we're talking about the same thing. Basically I'm saying that generally the URL bar and logs are considered more vulnerable than variables in memory. However, I think I would trust a value that's been transmitted from memory more than one that's been stored in localStorage but not transmitted, because the latter is trivial to grab with an extension. I'm not aware of any way for an extension to grab a variable from memory unless it knows how to access the variable itself from JS. This makes me wonder if there could be a security practice where you purposefully only store sensitive data like OAuth2 tokens in IIFEs in order to prevent extensions from accessing them. There's got to be some prior art on this. Anyway, thanks for bringing up the question. It's been a useful thought experiment.
- taeric 2y agoMakes sense and I agree there. The code flow has the advantage of not being in the url. I'm still unclear if I have a best practice on how to store the refresh token on a static website client. Feels off using local storage.
- apitman 2y agoIf you're in a situation where you would otherwise be using the implicit flow, can't you just throw the refresh token away? That should approximate the implicit flow.
- taeric 2y agoThis is what I'm currently doing. If my thread model includes malicious client, though, it doesn't work. Trivial to intercept.