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 >>> >>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
