Best practices according to whom?
This list, and documents such as: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics Wouldn't the concerns of section 6 of your draft better be parts of a follow-up or addendum to rfc-6749? OAuth 2.1 has no normative changes over OAuth 2.0, and includes all the docs and learnings that have come out since OAuth 2.0 was published. Creating a new version allows implementors to reference OAuth 2.1 and deployments will know that it is compliant with all the learnings rather than having to reference numerous, sometimes conflicting documents. A good example is PKCE -- it is best practice and deals with the security concerns -- but trying to understand what to do reading both 6749 and 7636 is non-trivial for many. While adding an addendum would solve a few of the issues addressed by the 2.1 doc -- the WG decided that the 2.1 doc was the approach to take. /Dick On Tue, Jun 14, 2022 at 12:12 AM Yannick Majoros <yann...@valuya.be> wrote: > Hello Aaron and anyone in the group, > > Could you further comment on my last email? > > I'd have an additional question: in > https://datatracker.ietf.org/doc/html/rfc6749#section-10 there is a list > of security considerations. Wouldn't the concerns of section 6 of your > draft better be parts of a follow-up or addendum to rfc-6749? > > Thanks, > > Yannick > > > Le sam. 11 juin 2022 à 20:55, Yannick Majoros <yann...@valuya.be> a > écrit : > >> >> 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 <aa...@parecki.com> 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 <yann...@valuya.be> >>> 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 >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> Yannick Majoros >> Valuya sprl >> >> > > -- > Yannick Majoros > Valuya sprl > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
