That's a very good point, I will see what I can adapt from your description below for the spec. I do think it's worth emphasizing like you say.
Aaron On Wed, Dec 5, 2018 at 7:15 PM Vittorio Bertocci <vitto...@auth0.com> wrote: > As mentioned during IIW when this pattern was borught up: I think readers > should receive a stronger warning about the known challenges of that > approach. Namely, assuming that the developer wants to perform API calls > from the browser: > - Making the app backend the true client for the AS is tantamount to > making the app backend act as an AS for the JS running in the browser. The > traffic between the JS layer and its backend for getting the initial token, > renewing tokens, doing stepup auth and the like is not codified in any > normative document- hence it's not threat modeled. Leaving it as exercise > to the reader without proper warnings seems reckless > - Various important providers indicate in the access token whether it was > issued to a confidential client or to a public one- and resources can rely > on that to make authorization decisions (for example allowing access only > to specific confidential clients). By having an app backend to act as a > proxy and pass those access tokens along to the JS layer, a resource might > be fooled into thinking that the caller is a confidential client, while in > fact the client is just a public client. Implementers choosing to use the > proxy pattern should either ensure resources refrain from using the nature > of the client (as certified by the access token) as input to authorization > decisions, or should have a way to signal to the AS that the tokens > requested are meant to be actually used by a weaker client hence should not > mark the ATs as issued to a confidential client. > > I am not suggesting that the document should necessarily contain this > level of detail, but I do think we should hint at those two challenges so > that readers have a better idea of the risks inherent to the approach with > today's tools. > > Related to this: if we think this pattern is common, we should consider > producing formal guidance on how to handle the necessary exchanges- or > we'll end up with a babel of proprietary ways of connecting the JS frontent > to the backend, with huge waste of cycles across the industry. > > On Tue, Dec 4, 2018 at 10:57 AM Aaron Parecki <aa...@parecki.com> wrote: > >> Thanks for all the discussion here. I've added the paragraph described to >> the document in a new "Architectural Considerations" section. Currently in >> the GitHub source code but not yet published as a new IETF draft, which >> will be coming shortly. >> https://github.com/aaronpk/oauth-browser-based-apps >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk <http://twitter.com/aaronpk> >> >> >> >> On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell <bcampb...@pingidentity.com> >> wrote: >> >>> I would also like to see something to that effect. I feel that sometimes >>> because SPAs use APIs, there's an unchallenged assumption that OAuth also >>> has to be used with the in-browser code accessing those APIs. Even if the >>> details are out of scope for this document, some text like the below at >>> least gives a nod to the possibility of different approaches, which may >>> ultimately be more secure and easier to mange. >>> https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#section-5.1 >>> kinda does this too but I'm a +1 for a little something along the lines of >>> what is being discussed recently in this thread. >>> >>> >>> >>> On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki <aa...@parecki.com> wrote: >>> >>>> I support adding something to that effect, but would like to make it >>>> clear that this removes the app from being covered under this BCP. How >>>> about: >>>> >>>> --- >>>> Implementations MAY consider moving the authorization code exchange and >>>> handling of access and refresh tokens to a backend component in order to >>>> avoid the risks inherent in handling access tokens from a purely browser >>>> based app. In this case, the backend component can be a confidential client >>>> and can be secured accordingly. >>>> >>>> Security of the connection between code running in the browser and this >>>> backend component is assumed to utilize browser-level protection >>>> mechanisms. Details are out of scope of this document. >>>> --- >>>> >>>> >>>> >>>> >>>> On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt < >>>> tors...@lodderstedt.net <tors...@lodderstedt..net>> wrote: >>>> >>>>> Interesting. Even on this list people felt to see that moving some >>>>> logic to a backend could solve some of the problems raised. What I want to >>>>> convey is: the solution to a problem in the OAuth space does not >>>>> necessarily need to be found on the OAuth protocol level. That’s a best >>>>> practice in the same way as some OAuth pattern. >>>>> >>>>> What I’m suggesting is a statement in the BCP like >>>>> >>>>> — >>>>> Implementations MAY consider to move authorization code exchange and >>>>> handling of access and refresh tokens to a backend component in order to >>>>> fulfill their security goals. >>>>> >>>>> Security of the connection between code running in the browser and >>>>> this backend component is assumed to utilize browser-level protection >>>>> mechanisms. Details are out of scope of this document. >>>>> — >>>>> >>>>> > Am 03.12.2018 um 11:19 schrieb John Bradley <ve7...@ve7jtb.com>: >>>>> > >>>>> > This is my point. >>>>> > >>>>> > From a security perspective we have a server based confidential >>>>> client... The fact that it has a angular or other JS UI protected by a >>>>> cookie seems to not be especially relucent to OAuth. >>>>> > >>>>> > Perhaps from the developer point of view they have a JS SPA and the >>>>> only difference to them is in one case they are including the OAuth client >>>>> and in the other they are using a server based proxy. So they see it as >>>>> the >>>>> same. >>>>> > >>>>> > Perhaps it is perspective. >>>>> > >>>>> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki <aa...@parecki.com >>>>> wrote: >>>>> > In this type of deployment, as far as OAuth is concerned, isn't the >>>>> backend web server a confidential client? Is there even anything unique to >>>>> this situation as far as OAuth security goes? >>>>> > >>>>> > I wouldn't have expected an Angular app that talks to its own server >>>>> backend that's managing OAuth credentials to fall under the umbrella of >>>>> this BCP. >>>>> > >>>>> > ---- >>>>> > Aaron Parecki >>>>> > aaronparecki.com >>>>> > >>>>> > >>>>> > >>>>> > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < >>>>> tors...@lodderstedt.net> wrote: >>>>> > the UI is rendered in the frontend, UI control flow is in the >>>>> frontend... just a different cut through the web app’s layering >>>>> > >>>>> > All Angular apps I have seen so far work that way. And it makes a >>>>> lot of sense to me. The backend can aggregate and optimize access to the >>>>> underlying services without the need to fully expose them. >>>>> > >>>>> > Am 02.12.2018 um 00:44 schrieb John Bradley <ve7...@ve7jtb.com>: >>>>> > >>>>> >> How is that different from a regular server client with a web >>>>> interface if the backed is doing the API calls to the RS? >>>>> >> >>>>> >> >>>>> >> >>>>> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>>>> >>> I forgot to mention another (architectural) option: split an >>>>> application into frontend provided by JS in the browser and a backend, >>>>> which takes care of the business logic and handles tokens and API access. >>>>> Replay detection at the interface between SPA and backend can utilize >>>>> standard web techniques (see OWASP). The backend in turn can use mTLS for >>>>> sender constraining. >>>>> >>> >>>>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < >>>>> tors...@lodderstedt.net>: >>>>> >>> >>>>> >>>> IMHO the best mechanism at hand currently to cope with token >>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >>>>> detection) and issue short living and privilege restricted access tokens. >>>>> >>>> >>>>> >>>> Sender constrained access tokens in SPAs need adoption of token >>>>> binding or alternative mechanism. mtls could potentially work in >>>>> deployments with automated cert rollout but browser UX and interplay with >>>>> fetch needs some work. We potentially must consider to warm up application >>>>> level PoP mechanisms in conjunction with web crypto. Another path to be >>>>> evaluated could be web auth. >>>>> >>>> >>>>> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < >>>>> hannes.tschofe...@arm.com>: >>>>> >>>> >>>>> >>>>> I share the concern Brian has, which is also the conclusion I >>>>> came up with in my other email sent a few minutes ago. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell >>>>> >>>>> Sent: Friday, November 30, 2018 11:43 PM >>>>> >>>>> To: Torsten Lodderstedt <tors...@lodderstedt.net> >>>>> >>>>> Cc: oauth <oauth@ietf.org> >>>>> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < >>>>> tors...@lodderstedt.net> wrote: >>>>> >>>>> >>>>> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen < >>>>> brockal...@gmail.com>: >>>>> >>>>> > >>>>> >>>>> > So you mean at the resource server ensuring the token was >>>>> really issued to the client? Isn't that an inherent limitation of all >>>>> bearer tokens (modulo HTTP token binding, which is still some time off)? >>>>> >>>>> >>>>> >>>>> Sure. That’s why the Security BCP recommends use of TLS-based >>>>> methods for sender constraining access tokens ( >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). >>>>> Token Binding for OAuth ( >>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as >>>>> well as Mutual TLS for OAuth ( >>>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options >>>>> available. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Unfortunately even when using the token endpoint, for SPA / >>>>> in-browser client applications, the potential mechanisms for >>>>> sender/key-constraining access tokens don't work very well or maybe don't >>>>> work at all. So I don't know that the recommendation is very realistic. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s)... Any >>>>> review, use, distribution or disclosure by others is strictly prohibited.. >>>>> If you have received this communication in error, please notify the sender >>>>> immediately by e-mail and delete the message and any file attachments from >>>>> your computer. Thank you. >>>>> >>>>> >>>>> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments >>>>> are confidential and may also be privileged. If you are not the intended >>>>> recipient, please notify the sender immediately and do not disclose the >>>>> contents to any other person, use it for any purpose, or store or copy the >>>>> information in any medium. Thank you. >>>>> >>>> _______________________________________________ >>>>> >>>> OAuth mailing list >>>>> >>>> OAuth@ietf.org >>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> OAuth mailing list >>>>> >>> >>>>> >>> oa...@ietf...org <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 >>>>> >>>>> -- >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk <http://twitter.com/aaronpk> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited.. >>> If you have received this communication in error, please notify the sender >>> immediately by e-mail and delete the message and any file attachments from >>> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
