> Am 24.07.2019 um 09:50 schrieb Tomek Stojecki > <tstojecki=40yahoo....@dmarc.ietf.org>: > > I agree that 6.1 takes too broad of a swipe, but I'd say with same-site > cookies and (sadly) without token-binding, the suggestion to use cookie based > session following oauth/oidc auth is a good one and should be incorporated > perhaps in 6.2?
Sure. Such mechanisms are also used in a backend based architecture for OAuth, just as a complement and not an alternative to OAuth > > Leo sums it up well here: >> We need to be clear on the distinction between browser based apps that hold >> the token(s) in the browser space, vs. those that don't. I agree that with >> this "common domain" architecture, the tokens should not be held in the >> browser, but it doesn't follow that oauth should not be used at all. > > Finally and sorry if this is off-topic, why isn't this discussion taking > place in github? Aaron has uploaded the document there. This medium, while > good for some things, seems to have a lot of shortcomings for this sort of > discussion and review. Well, since this is IETF ;-) > > Thanks, > Tomek > > > On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite > <da...@alkaline-solutions.com> wrote: > > > > > > > >> On Jul 23, 2019, at 12:47 PM, Brian Campbell >> <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: >> >> >> >>> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt >>> <tors...@lodderstedt..net> wrote: >>> >>> 2) Regarding architectures: I think this BCP should focus on >>> recommendations for securely implementing OAuth in the different potential >>> architecture.. I don’t think we should get into the business of >>> recommending and assessing other solutions (e.g. section 6.1.). Just to >>> give you an example: Section 6.1. states >>> >>> "OAuth and OpenID Connect provide very little benefit in this deployment >>> scenario, so it is recommended to reconsider whether you need OAuth or >>> OpenID Connect at all in this case.” >>> >>> Really? What experiences is this statement based on? In my experience, >>> sharing the same domain == host name tells you nothing about the overall >>> architecture of a certain deployment. There may be several reasons why >>> OAuth could be good choice in such a scenario, e.g. security considerations >>> (since your common domain is just a proxy server encapsulating a whole >>> universe of systems) or even modularity as an architecture principle. >>> >>> I suggest to remove section c. and to rephrase the second paragraph of the >>> abstract. >> >> I believe the experiences that the statement is based on are the predominant >> practice over the course of much of the history of the web of using a cookie >> to maintain an authenticated HTTP session in web applications. When the >> script of the browser-based application is served from a domain that can >> share cookies with the domain of the API, then cookies can still be used to >> authorize requests (even if those requests are API calls rather than full >> page HTTP request/response). And I do believe that's likely a better >> decision in a lot of such cases. >> >> That authenticated HTTP session may be establish from a username/password >> form submission, FIDO/WebAuthn, or whatever. Even as a result of an OpenID >> Connect flow. Or even SAML for that matter. But the the requests after that >> are authorized by the cookie. >> >> I think there's a tendency to assume because SPA style apps make API calls, >> they simply must use OAuth. Because API implies OAuth in the minds of many >> (which is a sign of its success). But OAuth isn't necessarily the only thing >> that can be used for API authorization. Cookies work too. I think/hope >> that's what Section 6.1. is getting at - providing some potential guidance >> that OAuth might not necessarily be the right choice in those cases where a >> common domain allows for a cookie. Perhaps the text in that section could be >> phased in a different or better way, but I think its useful to have some >> mention of in this document. >> >> Although taking out "and OpenID Connect" from the sentence quoted above >> might be more appropriate and alleviate some confusion. >> >> > > Perhaps it should be turned into a stated document assumption (that the > reader has decided to use OAuth) rather than guidance later in the document > (that OAuth may not be the best fit) > > There is AFAIK no set of security considerations or best practices we can > point to for “use some non-standardized system for acquiring and using > cookies” or even “here’s a standard for acquiring and using cookies”. > Omitting some of the moving pieces of OAuth might alleviate some security > concerns, but also resurrect some other security issues. The most immediate > example that comes to mind: using a HttpOnly cookie-as-token instead of an > access token may mean that you can’t have injected scripts exfiltrate the > token, but applying the access token was also a mitigation against browser > CSRF for your APIs. > > -DW > _______________________________________________ > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
