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
