Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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 b

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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 techniq

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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 mecha

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Hannes, > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig : > > I agree with Aaron here and I think Section 3.8.1.2 of > draft-ietf-oauth-security-topics-10 already does a pretty good job. my proposal is to add the following definition (based on 3.8.1.2) to a new „Terminology" section or

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

OAuth MTLS has been implemented in Banking industry so we have at least an alternative. Sender Constrained includes cases where it is not key bound but name bound as I understand and it may have some utility so we f there are doubts, mentioning the both may be good. Outlook for iOS

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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 On Behalf Of Brian Campbell Sent: Friday, November 30, 2018 11:43 PM To: Torsten Lodderstedt Cc: oauth Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I agree with Aaron here and I think Section 3.8.1.2 of draft-ietf-oauth-security-topics-10 already does a pretty good job. I was, however, wondering about the subtle implication of the requirement for sender constr