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 >> <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 listOAuth@ietf.orghttps://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
