I agree that there's a problem regarding the scope of this BCP . Or at least, I'm confused.
Is this BCP supposed to be all about the architecture where the browser holds the token(s)? If so, then a) let's just put that out front and center: that's the context of this BCP. That's what's meant by "browser-based application." b) It really IS limited to public clients. c) 6.2 simply doesn't belong: it is describing a different architecture. If, on the other hand, 6.2 is to be retained, it needs to be rephrased from saying the OAuth is not the right solution. Oauth can/will still be used, but the token(s) will be used server side, not client/browser side. - Leo On Mon, Jul 22, 2019 at 9:31 AM Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi Aaron, > > thanks for your continued work on the topic. > > Here are some general remarks on the current revision: > > 1) This BCP should not be limited to public clients. Your BCP itself > already describes an architecture where the OAuth client is a backend that > may be a confidential client (see section 6.2 for an example). The text of > the BCP generally seems to be inconsistent regarding oauth client types. > > I suggest to remove the second part of the first paragraph of the abstract > (“and should not be issued a client secret when registered.") and other > statements limiting the BCP to public clients. > > 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 6.1. and to rephrase the second paragraph of > the abstract. > > 3) The naming in section 6 focus on the ways the JS could be served. I > personally think the more important aspect is the architecture of the > overall application. > > I suggest the following changes: > - 6.2. Apps Served from a Dynamic Application Server -> SPA with backend > - 6.3. Apps Served from a Static Web Server -> SPA without backend > > Note: even an SPA with a backend could use a static web server to serve > the JS code. > > 4) I don’t understand why your BCP distinguishes 1st and 3rd party apps. > Neither the Native apps BCP nor security BCP do so and need to. > > 5) Section 9.8 seems to duplicate portions of the Security BCP (while not > giving the complete threat model) - what is the benefit of duplicating this > text? > > 6) I think the BCP would benefit from a refactoring. One idea would be to > first state the problem with implicit and give general recommendations > (PKCE and so on). The latter part could get into details of access and > refresh token protection in the context of different SPA architectures > (mTLS, CORS for CSRF prevention, …). > > kind regards, > Torsten. > > > On 9. Jul 2019, at 01:03, Aaron Parecki <aa...@parecki.com> wrote: > > > > Hi all, > > > > I've just uploaded a new version of oauth-browser-based-apps in > preparation for the meeting in Montreal. > > > > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 > > > > This draft incorporates much of the feedback I've received over the last > couple months, as well as what we discussed at the last meeting in Prague.. > > > > The primary change is a significant rewrite and addition of Section 6 to > highlight the two common deployment patterns, a SPA with and without a > dynamic backend. > > > > Please have a look and let me know what you think. I have a slot in the > agenda for Montreal to present on this as well. > > > > Thanks! > > > > ---- > > Aaron Parecki > > aaronparecki.com > > > > _______________________________________________ > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
