I think the BCP needs to point out there are solutions beyond an app directly interacting with AS and RSs from the browser. Otherwise people get the wrong impression this is the only way to go. To the contrary and as I pointed out, there are a lot of SPAs working as UI of a larger application.
Any multi user app needs a database. Will this database be directly exposed to the frontend? I don’t think so. There will be a backend, exposing relevant capabilities to the SPA. And if this app also uses external services, where do you want to store the respective refresh tokens? In the browser’s local storage? I don’t believe so. They will go into the same backend & database. And there are other reasons: No one will ever be able to implement a PSD2 TPP as a stand-alone SPA, obviously because it requires a confidential client but there are more aspects. Moreover, some security objectives can only be achieved if a backend is used.. That’s how the discussion started (token binding and the like). IMHO omitting this option significantly reduces the relevance of the BCP. I’m not saying we shall describe the interaction between frontend and backend in detail. I advocate for pointing out this option and its benefits. That’s it. > Am 03.12.2018 um 08:30 schrieb Hans Zandbelt <hans.zandb...@zmartzone.eu>: > > >> On Mon, Dec 3, 2018 at 4:18 AM David Waite <da...@alkaline-solutions.com> >> wrote: >> If (as Hans proposed) there was a mechanism for javascript to get access >> tokens to interact with protected resources in lieu of the client, there >> could be BCP around managing that (which would likely also overlap with a >> genuine javascript-in-browser client), but unfortunately there aren’t >> technical specs to support that sort of architecture yet. > > I agree with Aaron and David that this should be written up elsewhere and > hopefully be referred to from this BCP as it is relevant; anyone willing to > contribute and/or suggest where "elsewhere" is? > > Hans. > >> >> -DW >> >>> On Dec 2, 2018, at 4:43 PM, 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 >>>>>> 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 >>> _______________________________________________ >>> 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 > > > -- > hans.zandb...@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > 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
