Hello Dominick and everyone, I contributed to the latest drafts. I do share some concerns about the organization of the document, which can be improved. OTOH, some care has been put in the latest drafts about consistency (naming patterns and parts of systems in a similar way through all parts of the documents), and documenting security considerations per architectural pattern, including some pros and cons.
I do think that further documenting attacks, vulnerable architectures and their mitigations, would indeed help. Another opportunity for improvement could be to extract some reusable patterns, and adding some kind of overview, i.e. with a combination matrix. For example, off the top of my head, we have some aspects that could be mixed-and-matched into different architectural patterns: - client: A.backend/B.service worker/C.dom js - token storage/calling resource server: 1.backend 2.service worker 3.dom js (multiple subcases, e.g. local/session storage, web worker, closure) - refresh (token & flow): I. backend II. service worker III. no refresh token, prompt=none iframe at navigation A1I = BFF proxy A3I = Token Mediating Backend B2II or B2III = Service Worker client C3III = JS client none = single-domain app without oauth Each aspect brings its bunch of PROs and CONS which could be documented there (e.g. backends will typically open some CSS attack vector while local/session storage will open some token exfiltration in case of XSS). There are some other weird combinations, and they should also be explored (at least to document why they aren't recommended). I do think that whatever we do, this kind of document is difficult to read for someone with less experience in oauth. We can partly solve it, but we could also add some learning materials (cookbooks, security matrixes, ...). Do you have some examples of "jumping straight to conclusions without giving a good pro/con breakdown" which we could improve? Best regards, Yannick Le mar. 20 sept. 2022, 19:15, Dominick Baier <dba...@leastprivilege.com> a écrit : > Hi Aaron et al, > > I re-read the latest version of the web app BCP. For me it has become > increasingly hard to follow, and so I’m concerned that it’s even harder for > the target audience this document is intended for. > > It seems that over time more and more content got accumulated which IMO > jumps straight to conclusions without giving a good pro/con breakdown. I > worry that it will be hard for someone with less experience to make the > right choices (or easy to do the wrong ones). > > Given we both (and others here on that list) attended Philippe de Rycks > presentations at the OSW, I wonder if it wouldn’t make sense to start this > document with the browser attacker model. This would make it very clear > what an attacker is potentially able to do in the browser. > > From there this would lead to various risks/attacks like > > • Session hijacking > • Access token exfiltration > • Refresh token exfiltration > • … > > ..and based on that there are different implementation/architecture > choices to make. Each implementation style helps in mitigating one or more > of the above attacks. None of them will solve them all of course. > > I think this approach would make this document more useful and maybe you > can consider such a re-design. > > Thanks > Dominick > _______________________________________________ > 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
