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