>> There is a lot of debate around the question. Are these really security best practices? >The intent of this draft is to document the best practices today. If >anything in the document is not the best way to do something given the >documented constraints, then that should be revisited.
Best practices according to whom? There are various opinions on the subject, it's not black and white, so wouldn't it be best to be factual, e.g. describing attack X and counter-measures, and how solution Y is the best known tradeoff for that case. I indeed suggest section 6 to be revisited, as this the options described there are neither universally agreed upon, neither the best/only options to secure an application. I'd be happy to contribute, btw. I'm in the process of completing a kind of matrix which associates all known options (BFF, local/session storage/service worker/web worker/closure/token in a cookie/...), the security issues involved and their impact. I do also have POCs and further documentation for each solution, along with attack descriptions and their mitigations. > Did you consider using a service worker or other frontend solutions (web worker, closure...) for safe token storage? That would make a pure frontend solution at least as safe as cookies. This has been on my list to write up as another option. Great. I'd be interested in providing input here. Would it be useful? >> What if the backend is stateless and so doesn't have any session >You would need to use an encrypted session cookie to avoid storing >server-side state, but this is available in many web frameworks. Isn't that encrypted session cookie a kind of token? :-) Is this a best practice? Best regards, Yannick Le ven. 10 juin 2022 à 23:02, Aaron Parecki <[email protected]> a écrit : > Hi Yannick, answers inline: > > > There is a lot of debate around the question. Are these really security > best practices? > > The intent of this draft is to document the best practices today. If > anything in the document is not the best way to do something given the > documented constraints, then that should be revisited. > > > Did you consider using a service worker or other frontend solutions (web > worker, closure...) for safe token storage? That would make a pure frontend > solution at least as safe as cookies. > > This has been on my list to write up as another option. > > > Why would a cookie be safer, as this opens CSRF attacks that would make > the same actions available to a hacker that would be possible by getting > hold of a token (which might even be more difficult)? > > The assumption is that you would also protect against CSRF attacks > like any typical web application. > > > What if the backend is stateless and so doesn't have any session > > You would need to use an encrypted session cookie to avoid storing > server-side state, but this is available in many web frameworks. > > Aaron > > > On Fri, Jun 10, 2022 at 5:12 AM Yannick Majoros <[email protected]> wrote: > > > > Hello, > > > > Regarding "OAuth 2.0 for Browser-Based Apps" section 6 ( > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-09#section-6 > ), I do have some questions and concerns. Can I get in touch with someone > about this? > > > > My main questions are: > > - There is a lot of debate around the question. Are these really > security best practices? > > - Did you consider using a service worker or other frontend solutions > (web worker, closure...) for safe token storage? That would make a pure > frontend solution at least as safe as cookies. > > - Why would a cookie be safer, as this opens CSRF attacks that would > make the same actions available to a hacker that would be possible by > getting hold of a token (which might even be more difficult)? > > - What if the backend is stateless and so doesn't have any session > (which defeats 6.1 & 6.2 and leaves no option according to current draf)? > > > > Best regards. > > > > Yannick Majoros > > Valuya sprl > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > -- Yannick Majoros Valuya sprl
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
