I assume via the session context, carried as cookie, token or part of the URL.
> Am 02.12.2018 um 12:54 schrieb Rob Otto <robo...@pingidentity.com>: > > Apologies if I'm being dim (it wouldn't be the first time!) but how, in this > scenario, do we identify the browser client and authenticate it to the > backend, to associate it with the correct token(s)? > > Cheers (and really interesting discussion so far) > > Rob > >> On Sun, 2 Dec 2018 at 07:31, 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 > > > -- > > Rob Otto > EMEA Field CTO/Solutions Architect > robo...@pingidentity.com > > c: +44 (0) 777 135 6092 > Connect with us: > > > > > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
