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

[Aaron Parecki <[e-mail]>]

I support adding something to that effect, but would like to make it clear
that this removes the app from being covered under this BCP. How about:

---
Implementations MAY consider moving the authorization code exchange and
handling of access and refresh tokens to a backend component in order to
avoid the risks inherent in handling access tokens from a purely browser
based app. In this case, the backend component can be a confidential client
and can be secured accordingly.

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.
---




On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt <[e-mail]>
wrote:

> 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 <[e-mail]>:
> >
> > 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 <[e-mail] 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 <
> [e-mail]> 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 <[e-mail]>:
> >
> >> 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 <
> [e-mail]>:
> >>>
> >>>> 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 <
> [e-mail]>:
> >>>>
> >>>>> 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 <[e-mail]> On Behalf Of Brian Campbell
> >>>>> Sent: Friday, November 30, 2018 11:43 PM
> >>>>> To: Torsten Lodderstedt <[e-mail]>
> >>>>> Cc: oauth <[e-mail]>
> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <
> [e-mail]> wrote:
> >>>>>
> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <[e-mail]>:
> >>>>> >
> >>>>> > 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>>
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> --
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>