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

[Aaron Parecki <[e-mail]>]

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