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

[Aaron Parecki <[e-mail]>]

That's a very good point, I will see what I can adapt from your description
below for the spec. I do think it's worth emphasizing like you say.

Aaron


On Wed, Dec 5, 2018 at 7:15 PM Vittorio Bertocci <[e-mail]> wrote:

> As mentioned during IIW when this pattern was borught up: I think readers
> should receive a stronger warning about the known challenges of that
> approach. Namely, assuming that the developer wants to perform API calls
> from the browser:
> - Making the app backend the true client for the AS is tantamount to
> making the app backend act as an AS for the JS running in the browser. The
> traffic between the JS layer and its backend for getting the initial token,
> renewing tokens, doing stepup auth and the like is not codified in any
> normative document- hence it's not threat modeled. Leaving it as exercise
> to the reader without proper warnings seems reckless
> - Various important providers indicate in the access token whether it was
> issued to a confidential client or to a public one- and resources can rely
> on that to make authorization decisions (for example allowing access only
> to specific confidential clients). By having an app backend to act as a
> proxy and pass those access tokens along to the JS layer, a resource might
> be fooled into thinking that the caller is a confidential client, while in
> fact the client is just a public client. Implementers choosing to use the
> proxy pattern should either ensure resources refrain from using the nature
> of the client (as certified by the access token) as input to authorization
> decisions, or should have a way to signal to the AS that the tokens
> requested are meant to be actually used by a weaker client hence should not
> mark the ATs as issued to a confidential client.
>
> I am not suggesting that the document should necessarily contain this
> level of detail, but I do think we should hint at those two challenges so
> that readers have a better idea of the risks inherent to the approach with
> today's tools.
>
> Related to this: if we think this pattern is common, we should consider
> producing formal guidance on how to handle the necessary exchanges- or
> we'll end up with a babel of proprietary ways of connecting the JS frontent
> to the backend, with huge waste of cycles across the industry.
>
> On Tue, Dec 4, 2018 at 10:57 AM Aaron Parecki <[e-mail]> wrote:
>
>> Thanks for all the discussion here. I've added the paragraph described to
>> the document in a new "Architectural Considerations" section. Currently in
>> the GitHub source code but not yet published as a new IETF draft, which
>> will be coming shortly.
>> https://github.com/aaronpk/oauth-browser-based-apps
>>
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk <http://twitter.com/aaronpk>
>>
>>
>>
>> On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell <[e-mail]>
>> wrote:
>>
>>> I would also like to see something to that effect. I feel that sometimes
>>> because SPAs use APIs, there's an unchallenged assumption that OAuth also
>>> has to be used with the in-browser code accessing those APIs. Even if the
>>> details are out of scope for this document, some text like the below at
>>> least gives a nod to the possibility of different approaches, which may
>>> ultimately be more secure and easier to mange.
>>> https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#section-5.1
>>> kinda does this too but I'm a +1 for a little something along the lines of
>>> what is being discussed recently in this thread.
>>>
>>>
>>>
>>> On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki <[e-mail]> wrote:
>>>
>>>> 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] <torsten@lodderstedt..net>> 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
>>>>> >>>
>>>>> >>> OAuth@ietf...org <[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>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> *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.*
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>