These are exactly the kinds of things I would expect to see in the Browser-based app BCP. There isn't one best way to do things, but it's worth pointing out the options and the tradeoffs of each. Some people may not share the same concerns as others, but it's useful to point out the different options and the tradeoffs. If you're willing to contribute to the doc, I'd be happy to set up some time to talk offline about how to make that happen.
Aaron On Wed, Jun 15, 2022 at 4:08 AM Yannick Majoros <yann...@valuya.be> wrote: > Hello, > > >>Best practices according to whom? > > >This list, and documents such as: > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics > > According to the explanation about rfc-6749 / oauth 2.1 and the PKCE > example, it seems that document would indeed be the right place to document > security issues and their workarounds. > > But I don't see any justification for section 6 in that document (which is > also a draft BTW). That document seems to not say much about token storage, > unless I'm mistaken. > > I am aware of discussions about potential issues about in-browser token > storage and the risks they involve, mostly in case of successful XSS. As > you all know, the point is also quite controversial, as there are also > voices arguing that this isn't the main attention point: in case of XSS, > the user is actually impersonated anyway and actually getting hold of the > token is a moot point, as accessing all protected resources is then > trivial, the client having all necessary technical means for that. > > If protecting tokens from the client (typically, javascript frontend) > after successful XSS is still a point, which it seems to be for some people > according to various widespread resources (though not universally so), > there are options for that which are at least as secure as a stateful BFF. > > For example, a service worker can effectively isolate tokens and call a > resource server in a safe way, with the frontend having no token access at > all: > [image: image.png] > > OTOH, a commonly (though not consensual) recommended solution is a > stateful BFF. Popular common sense is that it's safe to leakage because of > HTTPOnly cookies, but that's actually not the case. Here is an example of > exploit, once XSS has happened (which is the actual problem, not > javascript-accessible token storage): > [image: image.png] > This attack isn't even specific to HTTPOnly cookies: it can be made to > target any form of secret (tokens or cookies) in an *authorization code* > flow. But this illustrates that cookies aren't inherently safer than, say, > a *service worker*. > > For these reasons, I suggest: > - documenting that kind of security issues in the *OAuth 2.0 Security > Best Current Practice* document > - recommend more alternatives (e.g. service/web workers, among others), or > instead even focusing attention on XSS > - rewriting section 6 to not mislead people into thinking that pure > frontend / pure SPA solutions are inherently less safe than cookie-based > approaches. > - generally focusing on documenting attacks and countermeasures, as > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics is > doing quite well :-) > > How can we improve the current situation? Would it be useful to list and > detail some attacks that are not documented in the *OAuth 2.0 Security > Best Current Practice* document? Would submitting a new draft for > frontends be a good idea? > > Best regards, > > Yannick Majoros > > Le mer. 15 juin 2022 à 04:11, Dick Hardt <dick.ha...@gmail.com> a écrit : > >> >> >> 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 >>> >> > > -- > Yannick Majoros > Valuya sprl > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
